Flussdiagramm Datenzugriffsantrag: vom Antrag bis zum Entzug
Flussdiagramm für den Datenzugriffsantrag: Zweck angeben, Klassifizierung lesen, den Dateneigentümer entscheiden lassen, Datenschutz prüfen, befristet gewähren, rezertifizieren oder entziehen.
Was ist flussdiagramm datenzugriffsantrag: vom antrag bis zum entzug?
Anträge auf Daten werden meist so behandelt wie Anträge auf Software. Ein Ticket bittet um Zugriff auf das Data Warehouse, wer die Zugangsdaten verwaltet, gewährt ihn, und jemand, der für eine einzige Frage eine einzige Tabelle gebraucht hätte, kann am Ende jedes Schema auf dem Cluster lesen: auch die mit Gehältern, Patientendaten oder Kartennummern. Drei Gewohnheiten richten den größten Teil des Schadens an. Die freigebende Stelle wird danach ausgewählt, wer den Zugriff technisch erteilen kann, und nicht danach, wer für die Daten einsteht. Der Antrag nennt ein System statt eines Zwecks, sodass es nichts gibt, woran sich Least Privilege (das Prinzip der minimal notwendigen Rechte) überhaupt messen ließe. Und die Freigabe hat kein Enddatum, also überlebt sie das Projekt, danach den Teamwechsel und gelegentlich das Arbeitsverhältnis. Datenzugriff ist außerdem die eine Art von Zugriff, bei der fast immer eine kleinere Antwort möglich wäre (eine maskierte Spalte, ein Filter auf Zeilenebene, eine vorab aggregierte Tabelle), und niemand bietet sie an, weil das Anbieten länger dauert als das Freigeben der Rohtabelle. Das Ergebnis ist eine Landschaft, in der niemand sagen kann, wer was lesen darf, und in der kein einziger Antrag für sich genommen unangemessen war.
Dieses Diagramm handelt von Datenbeständen, nicht von Konten. Braucht jemand, der bereits im Unternehmen arbeitet, eine weitere Anwendung, und lautet die Frage nur, wer freigibt und wer einrichtet, dann ist das der allgemeine Berechtigungsantrag unter /de/templates/berechtigungsantrag-prozess; die von einem Eintritt oder Wechsel im Personalsystem ausgelöste Variante steht unter /de/templates/berechtigungsvergabe-mitarbeiter-prozess. Das Anlegen, Ändern und Deaktivieren der Identität selbst (Konto, Verzeichnisgruppe, Lizenz) gehört in das User Provisioning unter /de/templates/user-provisioning-prozess; alles hier setzt voraus, dass die antragstellende Person bereits ein funktionierendes Konto hat, und fragt allein, was dieses Konto lesen darf. Ebenso wenig geht es um eine Anfrage von außen: Verlangt eine Person Auskunft über ihre eigenen personenbezogenen Daten, löst das eine gesetzliche Pflicht mit eigener Frist, eigener Identitätsprüfung und eigenen Ablehnungsgründen aus: gezeichnet unter /de/templates/betroffenenanfrage-prozess-dsgvo. Und sind Daten bereits dorthin gelangt, wo sie nicht hingehören, ist dies das falsche Diagramm: Eindämmung, die Risikobewertung für die Betroffenen und die Entscheidung über die Meldung binnen 72 Stunden stehen unter /de/templates/datenpanne-meldeprozess-dsgvo. Was hier bleibt, ist eng und konkret: eine interne Person, ein benannter Datenbestand, ein angegebener Zweck und ein Eigentümer, der entscheidet.
Die Entscheidungen, die die meisten geschriebenen Zugriffsverfahren der Gewohnheit überlassen, sind hier ausdrücklich gezeichnet. „Katalogisiert mit benanntem Eigentümer?“ steht vor jeder Bewertung, denn ein Datenbestand ohne Eigentümer kann von niemandem freigegeben werden, und die ehrliche Lage ist in den meisten Organisationen, dass erst der erste Antrag auf eine Tabelle dazu führt, dass sie klassifiziert wird; der Nein-Zweig läuft über die Katalogisierung zurück, statt zu der Person zu eskalieren, die zufällig die Pipeline gebaut hat. „Welchen Zugriff erfordert der Zweck?“ ist eine dreifache Verzweigung und keine Ja-Nein-Frage, damit der maskierte oder aggregierte Weg auf dem Diagramm existiert und ausdrücklich ausgeschlossen werden muss, statt nie erwähnt zu werden. Und der Prozess endet nicht mit der Freigabe: „Vor Ablaufdatum rezertifiziert?“ macht das Ablaufen zum Normalfall und die Verlängerung zur Ausnahme (das Gegenteil dessen, wie Zugriffsrechte tatsächlich gehalten werden), während „Rolle oder Zweck geändert?“ dem Eigentümer einen zweiten Anlass zum Entzug gibt, der nicht auf einen Überprüfungstermin wartet. Der Notfallweg ist aus demselben Grund gezeichnet: Wer mit einer Produktionsstörung an die Daten muss, kommt auf die eine oder andere Weise heran, und deshalb stellt „Nachträgliche Freigabe erteilt?“ Bestätigung und Entzug hinter den Notfallzugriff, statt so zu tun, als gäbe es ihn nicht.
Was dieses Flussdiagramm abdeckt
In dieser Vorlage
- Fünf Bahnen (Antragsteller, Data Steward, Dateneigentümer, Datenschutz und Datenplattform-Team) über fünf Phasen: Antrag, Klassifizierung, Prüfung durch Eigentümer, Einrichtung sowie Überprüfung und Entzug.
- Ein Antrag, der einen Grund tragen muss: „Antrag mit Zweckangabe stellen“ ist der einzige reguläre Weg hinein, während die Verzweigung „Notfallzugriff bei Störung?“ Fälle mit Produktionsstörung direkt auf „Protokollierten Notfallzugriff gewähren“ leitet, statt sie neben dem Diagramm geschehen zu lassen. Diese Freigabe trifft anschließend auf „Nachträgliche Freigabe erteilt?“ und endet bei „Notfallzugriff entzogen und eskaliert“, wenn sie niemand bestätigt.
- „Katalogisiert mit benanntem Eigentümer?“ in der Bahn Data Steward, deren Nein-Zweig über „Klassifizieren und Dateneigentümer benennen“ zurück zur Suche im Katalog führt, sodass ein Datenbestand ohne Eigentümer nicht stillschweigend freigegeben werden kann.
- Die Entscheidung liegt beim Dateneigentümer und nicht bei der IT: „Zweck und Least Privilege prüfen“, danach „Zweck rechtfertigt den Zugriff?“, dessen Nein-Zweig bei „Antrag abgelehnt, Gründe dokumentiert“ endet, und „Personenbezogene Daten betroffen?“, das in die Bahn Datenschutz leitet.
- Ein Datenschutzzweig mit echten Zähnen: „Rechtsgrundlage festhalten und Felder minimieren“, danach die dreifache Entscheidung „Datenschutzprüfung gibt Nutzung frei?“, die den Antrag freigibt, ihn auf denselben Ablehnungsendpunkt führt oder ihn über „DSFA durchführen und Auflagen festlegen“ schickt und für eine zweite Antwort zurückbringt, sobald das Restrisiko bekannt ist.
- Die dreifache Entscheidung „Welchen Zugriff erfordert der Zweck?“: maskiert oder aggregiert, streng vertrauliche Rohdaten (mit dem zusätzlichen Schritt „Datennutzungsvereinbarung unterzeichnen“) oder interne Rohdaten, die alle in „Zugriff mit Ablaufdatum gewähren“, Abfrageprotokollierung und einen Registereintrag münden. „Rolle oder Zweck geändert?“ und „Vor Ablaufdatum rezertifiziert?“ führen anschließend zurück zu einer neuen Freigabe oder hinaus zu „Zugriff entzogen, Register aktualisiert“.
Wann Sie diese Vorlage verwenden sollten
- Sie schreiben den Zugriffsteil einer Data-Governance- oder Datenmanagement-Richtlinie für ein Data Warehouse, ein Lakehouse oder eine Reporting-Schicht und brauchen eine Seite, die zeigt, dass der Dateneigentümer entscheidet und nicht das Team, das die Zugangsdaten verwaltet.
- Ihre Analystinnen und Analysten halten Zugriffe, die für längst abgeschlossene Projekte gewährt wurden, und Sie wollen Ablauf und Rezertifizierung im Prozess verankert sehen statt als jährliche Aufräumaktion, die niemand gern macht.
- Sie konfigurieren einen Antragsworkflow in einem Datenkatalog oder in einem Werkzeug für Access Governance und wollen den Freigabeweg und die Schwellen der Klassifizierung abgestimmt haben, bevor sie in Konfiguration gegossen werden.
- Ihre Entwicklungsteams haben einen Notfallweg in die Produktionsdaten, den hinterher niemand prüft, und Sie brauchen Bestätigung und Entzug dort gezeichnet, wo Dateneigentümer und Rufbereitschaft sie beide sehen.
- Datenschutz und Datenplattform-Team streiten regelmäßig darüber, wer über personenbezogene Daten entscheidet, und Sie wollen Rechtsgrundlage, Minimierung und DSFA im Ablauf verortet haben statt hinten angehängt.
So funktioniert es
Benennen Sie die Bahnen nach Ihrer eigenen Organisation
Ersetzen Sie Antragsteller, Data Steward, Dateneigentümer, Datenschutz und Datenplattform-Team durch die Rollen, die es bei Ihnen wirklich gibt. Halten Sie den Dateneigentümer vom Plattformteam getrennt, selbst wenn heute dieselbe Person beides macht: Genau das Zusammenlegen erzeugt den Prozess, in dem die freigebende und die einrichtende Stelle identisch sind. Gibt es keine eigene Datenschutzfunktion, benennen Sie die Person, die die Verantwortung trägt, statt die Bahn zu löschen; und ist die Rolle des Data Stewards bei Ihnen informell, setzen Sie die fachliche Leitung der Domäne dorthin und schreiben Sie das auf.
Schreiben Sie Ihr Klassifizierungsschema in das Diagramm
„Klassifizierung und Handhabungsregeln lesen“ bleibt wirkungslos, solange die Stufen nicht existieren. Benennen Sie sie (öffentlich, intern, vertraulich, streng vertraulich oder was auch immer Ihr Schema verwendet) und halten Sie zu jeder fest, was sie erlaubt: nur Abfrage im System, Extraktion zulässig, Maskierung verpflichtend, unterzeichnete Vereinbarung erforderlich. Legen Sie dann fest, welche Stufe den Zweig mit der Nutzungsvereinbarung auslöst und welche Stufe die Analyseumgebung nie verlassen darf. Ohne diese Tabelle wird jeder Antrag von Grund auf neu diskutiert, und die Antworten driften mit der freigebenden Person.
Lassen Sie die Zweckangabe echte Arbeit leisten
Legen Sie fest, was ein Antrag mindestens sagen muss: die Frage, die beantwortet werden soll, die benötigten Tabellen und Spalten, wessen Daten betroffen sind, für wie lange der Zugriff gebraucht wird und wo ein etwaiger Auszug gespeichert wird. „Für Auswertungen“ gehört zurückgegeben und nicht freigegeben. Das ist die billigste Kontrolle auf dieser Seite, denn ein sauber geschriebener Zweck macht die Prüfung auf minimal notwendige Rechte, die Maskierungsentscheidung und das Ablaufdatum nahezu mechanisch, während ein vager Zweck alle drei willkürlich macht.
Setzen Sie Standardfristen je Klassifizierungsstufe
Hinterlegen Sie zu „Zugriff mit Ablaufdatum gewähren“ je Stufe einen Standard: das Störungsfenster für den Notfallzugriff, etwa 90 Tage für streng vertrauliche Daten, sechs oder zwölf Monate für interne Daten und das Enddatum des Projekts, wo es eines gibt. Lassen Sie kürzere Fristen auf Wunsch zu und machen Sie alles, was über den Standard hinausgeht, zu einer ausdrücklichen Entscheidung des Eigentümers. Das Ablaufdatum ist die Kontrolle, die Reorganisationen, Werkzeugwechsel und das allgemeine Vergessen des Prozesses überlebt.
Vereinbaren Sie den Notfallweg, bevor Sie ihn brauchen
Entscheiden Sie, wer den Notfallzugriff auslösen darf, was er gewährt, über welches Konto er läuft, wie die Sitzung protokolliert wird und wer im Moment der Freigabe alarmiert wird. Setzen Sie danach die Frist für die nachträgliche Bestätigung (wenige Arbeitstage) und, wichtiger noch, legen Sie fest, was geschieht, wenn niemand bestätigt. Der automatische Entzug zum Fristende ist die einzige Variante, die hält, denn eine Warteschlange nachträglicher Freigaben ohne Konsequenz ist binnen eines Quartals ein dauerhafter Rückstand.
Gehen Sie es durch und veröffentlichen Sie eine Fassung
Nehmen Sie das fertige Diagramm zu einem Dateneigentümer, zu einer Person, die häufig Zugriff beantragt, zu der Person, die die Freigaben technisch einrichtet, und zum Datenschutz, und prüfen Sie es an drei echten Anträgen aus dem letzten Quartal, darunter einer, der abgelehnt wurde, und einer, der über den Notfallweg lief. Korrigieren Sie das Diagramm auf das, was tatsächlich geschehen ist, und nicht auf das, was die Richtlinie sagt. Veröffentlichen Sie dann diese Fassung, behalten Sie die älteren und verlinken Sie sie aus der Data-Governance-Richtlinie, damit erkennbar bleibt, welche Version jemand vor sich hat.
Häufig gestellte Fragen
Welche Schritte umfasst ein Prozess für Datenzugriffsanträge?
Einen Antrag stellen, der den Zweck nennt und nicht das System; den Datenbestand im Katalog finden und seine Klassifizierung und Handhabungsregeln lesen; bestätigen, dass er einen benannten Eigentümer hat, und ihn andernfalls zuerst klassifizieren; diesen Eigentümer den Zweck gegen die minimal notwendigen Rechte prüfen und entscheiden lassen; bei personenbezogenen Daten die Rechtsgrundlage festhalten, die Felder minimieren und den Fall durch die Datenschutzprüfung oder eine Datenschutz-Folgenabschätzung führen; vor dem Rohzugriff eine maskierte oder aggregierte Sicht anbieten; für streng vertrauliche Daten eine unterzeichnete Nutzungsvereinbarung ergänzen; den Zugriff mit Ablaufdatum gewähren; die Abfrageprotokollierung aktivieren; die Berechtigung im Zugriffsregister erfassen; und sie danach entweder vor dem Ablauf rezertifizieren oder entziehen: sofort, wenn sich Rolle oder Zweck ändern. In der Praxis fehlen am häufigsten dieselben drei Schritte: die maskierte Alternative, das Ablaufdatum und der Auslöser für den Entzug bei einem Rollenwechsel.
Wer sollte den Zugriff auf einen Datenbestand freigeben: die IT oder der Dateneigentümer?
Der Dateneigentümer, also die im Fachbereich verantwortliche Person für den Gegenstand, den die Daten beschreiben, und nicht das Team, das die Plattform betreibt, auf der sie liegen. Zu beurteilen ist, ob dieser Zweck diese Daten rechtfertigt, und das kann nur jemand, der versteht, was die einzelnen Datensätze bedeuten. Das Plattformteam führt die Freigabe aus, setzt das Ablaufdatum und aktiviert die Protokollierung; es sollte nicht zusätzlich darüber entscheiden, wer Entgelt-, Patienten- oder Kundendaten lesen darf. Eine Freigabe durch die Führungskraft lohnt sich als erstes Tor, weil sie bestätigt, dass der Antrag zur Aufgabe der Person gehört, ersetzt aber die Entscheidung des Eigentümers nicht. Hat ein Datenbestand tatsächlich keinen Eigentümer, ist das für sich genommen ein Befund: Deshalb stellt dieses Diagramm „Katalogisiert mit benanntem Eigentümer?“ vor die Prüfung und nicht dahinter.
Wie lange sollte ein Datenzugriff gelten, bevor er abläuft?
So lange, wie der angegebene Zweck es erfordert, und keinen Tag länger, mit einem Standard, der sich aus der Klassifizierung ergibt und nicht je Antrag ausgehandelt wird. Ein tragfähiges Muster ist: die Dauer der Störung beim Notfallzugriff, rund 90 Tage für streng vertrauliche oder personenbezogene Daten, sechs bis zwölf Monate für gewöhnliche interne Daten und das Projektende, wenn der Antrag an ein Projekt gebunden ist. Wichtiger als die Zahlen ist der Mechanismus: Ein Ablaufdatum macht den Entzug zum Normalfall und die Verlängerung zur bewussten Handlung, sodass Rechte von selbst verfallen, wenn der Prozess vernachlässigt wird. Zugriff ohne Ablaufdatum sammelt sich stattdessen an. Wenn Sie einen Eigentümer um die Rezertifizierung bitten, schicken Sie die Zahl der Abfragen mit: Eine Berechtigung, die seit sechs Monaten niemand genutzt hat, wird ohne Diskussion entzogen, während eine bloße Namensliste ohne Nutzungsdaten fast immer pauschal bestätigt wird.
Wann braucht ein Datenzugriffsantrag eine Datenschutz-Folgenabschätzung?
Nach Art. 35 DSGVO ist eine Datenschutz-Folgenabschätzung (DSFA) erforderlich, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat; ausdrücklich genannt sind unter anderem die umfangreiche Verarbeitung besonderer Kategorien personenbezogener Daten, die systematische umfangreiche Überwachung öffentlich zugänglicher Bereiche und die systematische umfassende Bewertung persönlicher Aspekte, auf die automatisierte Entscheidungen mit rechtlicher Wirkung gestützt werden. Die Aufsichtsbehörden veröffentlichen darüber hinaus nach Art. 35 Abs. 4 DSGVO Listen von Verarbeitungsvorgängen, für die eine DSFA in jedem Fall durchzuführen ist. Für einen internen Auswertungsantrag sind die ehrlichen Auslöser meist der Umfang der betroffenen Population, ob es sich um besondere Kategorien oder um Daten zu Straftaten handelt, ob die Betroffenen mit dieser Nutzung vernünftigerweise rechnen und ob das Ergebnis in eine Entscheidung über sie einfließt. Zwei Dinge helfen in der Praxis: jeden Antrag mit Personenbezug zu screenen, statt auf einen Einwand zu warten, und das Ergebnis als Auflagen an die Freigabe zu binden (maskierte Spalten, Aufbewahrungsdauer, Verbot der Re-Identifizierung) statt als Dokument, das abgelegt und vergessen wird. Betrifft die Auswertung Beschäftigtendaten, kommt in Deutschland die Mitbestimmung hinzu: Technische Einrichtungen, die dazu bestimmt oder objektiv geeignet sind, Verhalten oder Leistung der Beschäftigten zu überwachen, unterliegen § 87 Abs. 1 Nr. 6 BetrVG und werden üblicherweise in einer Betriebsvereinbarung geregelt.
Worin unterscheidet sich das von einem allgemeinen Berechtigungsantrag?
Der allgemeine Berechtigungsantrag unter /de/templates/berechtigungsantrag-prozess deckt Systeme und Anwendungen ab: Jemand braucht eine Rolle in einem Fachsystem, Führungskraft und Systemverantwortlicher geben frei, die Funktionstrennung wird geprüft, und die IT richtet ein. Diese Seite deckt Datenbestände ab, und dadurch ändern sich drei Dinge. Freigebende Stelle ist der Dateneigentümer und nicht der Systemverantwortliche, weil es um die Bedeutung der Datensätze geht und nicht um die Funktion einer Anwendung. In der Mitte steht ein Schritt zur Klassifizierung, weil die Antwort davon abhängt, was in der Tabelle steht. Und es gibt die maskierte oder aggregierte Alternative, für die es beim Anwendungszugriff keine Entsprechung gibt: Man kann niemandem 60 Prozent eines Finanzmoduls geben, wohl aber eine Sicht, aus der die Identifikatoren entfernt sind. Entwerfen Sie ein Service-Desk-Formular für Anwendungszugriffe, beginnen Sie beim allgemeinen Prozess; regeln Sie, wer das Data Warehouse abfragen darf, beginnen Sie hier.