Bei der Abfrage von Polizeidatenbanken gibt es komfortable Suchoptionen. Manche können für trickreiche Abfragen und mehr genutzt werden. Die Ansichten bei Medien und in der Öffentlichkeit über das Ausmaß der Protokollierung solcher Abfragen und die möglichen Auswirkungen auf die positiven Ergebnisse bei der Suche nach Datendieben gehen weit an den tatsächlichen Gegebenheiten vorbei. Damit beschäftigt sich dieser letzte Teil unserer Artikelserie, auch anhand von Fallbeispielen zur Datenbanknutzung über Journalisten, die zu deren Ausschluss beim G20-Gipfel in Hamburg führten. Und anhand der Auswertung von Protokollen über polizeiliche Aktivitäten, die der unberechtigten Inhaftierung des jungen Syrers Amad A. vorausgingen, der in der JVA Kleve nach einem Zellenbrand gestorben ist. | Lesedauer: Ca. 15 Minuten
Suchfragen und andere Optionen bei der Datenbankabfrage
Die bisher genannten Datenbanken – von Polizei oder von anderen Behörden – bieten JEDEM Polizeivollzugsbeamten einen entsprechenden Zugang.
Mit welcher Anwendung wird die Suche durchgeführt?
Es ist jedoch von Polizeibehörde zu Polizeibehörde unterschiedlich, welche Anwendung für die Datenbankabfrage genutzt wird. In der Mehrheit der Bundesländer, insbesondere denen, die POLAS als INPOL-Landessystem einsetzen, ist dies der so genannte INPOL-LAND-Auskunfts-Client (ILAC).
Eine Ausnahme bildet Niedersachsen. POLAS ist dort als INPOL-Land-System eingesetzt, für Suchen in Polizeidatenbanken und denen anderer Behörden kommt NIVADIS zum Einsatz (Niedersächsisches Vorgangsbearbeitungs-, Analyse-, Dokumentations- und Informations-System). Auch in Berlin und Nordrhein-Westfalen ist die Datenbankabfrage in das Landes-Vorgangsbearbeitungssystem integriert. Im Unterschied zu Niedersachsen arbeiten diese beiden Länder jedoch nicht (mehr) mit POLAS. Vielmehr ist das INPOL-Landessystem eine Teilkomponente des Vorgangsbearbeitungssystems POLIKS (Berlin) bzw. ViVA (NRW). Die entsprechende INPOL-Land-Datenbank ist ins Vorgangsbearbeitungssystem integriert.
Gleichzeitige Abfrage von verschiedenen Datenbanken mit einer Suchfrage
Die Vorgangsbearbeitungssysteme POLIKS und ViVA erlauben es, mehrere Polizei- und sonstige Datenbanken mit EINER Suchfrage abzufragen: Dazu werden die Kriterien für die Frage in eine Bildschirmmaske eingetragen: Zum Beispiel Familienname, Vorname und Geburtsdatum der gesuchten Person.
Das klingt vordergründig komfortabel. In der Praxis hat die Funktion jedoch einen Pferdefuß. Denn die verschiedenen Datenbanken, die da abgefragt werden, haben unterschiedliche Regeln darüber, wann eine Suchfrage syntaktisch zulässig ist oder nicht. Manchmal reichen schon zwei Namensbestandteile, im anderen Fall muss zusätzlich noch ein drittes Kriterium (z.B. Geburtsdatum) eingegeben werden. Wenn solche Feinheiten, dem Benutzer nicht bewusst sind, wird es zu Fehlinterpretationen von Ergebnissen kommen. Weil ein Nicht-Treffer eben auch zustande kommen kann, weil die Suchkriterien nicht ausreichend waren, um überhaupt eine Suche auszulösen.
Wie wird die Suchfrage formuliert?
Der Anwender gibt dazu die Suchbegriffe in eine Suchmaske ein, also z.B. für eine gesuchte Person Karlheinz Meier den Nachnamen ins Nachnamen-Feld, den Vornamen ins Vornamen-Feld und ggf. noch ein Geburtsdatum in das dafür vorgesehene Feld.
Phonetische Suche
Wenn er sich nicht sicher ist, wie der Karlheinz Meier tatsächlich erfasst worden ist, kann er eine phonetische Suche zuschalten. Das ist eine feine Sache. Besonders, wenn es um Namen geht, die – obwohl gleich ausgesprochen – in verschiedener Schreibweise vorkommen können: So wie bei Maier, Mayer, Mair, Mayr, Meier, Meyer usw. oder den diversen Schmidts usw. Oder wie bei Karl Heinz, Karlheinz oder Karl-Heinz.
Viele Polizeidatenbanken bieten die Möglichkeit der phonetischen Suche für Personennamen an. Dann wird der eingegebene Name nicht nur exakt in der Schreibweise gesucht, mit der er erfasst wurde. Sondern zusätzlich auch in allen sonstigen Schreibweisen, die zu diesem (gesprochenen) Homonym (= gleich LAUTENDEN Namen) passen.
Die Arbeit hinter solche phonetischen Suchen leisten spezialisierte Algorithmen: Die spezifisch sind für einen bestimmten Sprachraum. Für den deutschen Sprachraum wird die Kölner Phonetik eingesetzt. Für den englischsprachigen Raum ist Soundex weit verbreitet; sie liefert auch für deutsche Namen brauchbare Ergebnisse.
Schwierigkeiten sind zu erwarten bei der phonetischen Suche für Namen aus anderen Namens- und Zeichenräumen, wie arabische oder asiatische Namen. Zumal solche Namen ja zunächst in „unser“ ZEICHENsystem übertragen werden mussten (, was dem Gutdünken und „Können“ des ersterfassenden Beamten überlassen bleibt). Und das dabei entstehende Gebilde dann auch noch phonetisch variiert wird. Dabei kommt etwas relativ Unscharfes heraus, nicht immer etwas linguistisch Brauchbares. Zumal auch die Namen aus anderen Kulturräumen nicht ohne erheblichen Bedeutungsverlust übertragen werden können in die Namensbildung unseres deutschsprachigen Kulturraums.
Wie einer die phonetische Suche missbrauchen kann, der rumschnüffeln will …
Ein Pfiffikus unter den Informations-Piraten könnte die phonetische Suche dazu benutzen, nach Personen rumzuschnüffeln, obwohl er deren genauen Namen gar nicht eingibt. Daher wird dieser Name auch gar nicht im Protokoll der Abfragen auftauchen. Und somit auch keinerlei „Verdacht“ aufwerfen.
Mal angenommen, unser Pfiffikus interessiere sich für einen Menschen namens Andy Scheuer. In der Suchmaske gibt er allerdings die Namensbestandteile „Andi“ und „Schoier“ ein. Ein System mit der entsprechenden phonetischen Suchoption wird dann als Treffer auch den eigentlich interessierenden ‚Andi Scheuer‘ als Treffer liefern *]. Und niemand wird bei einer späteren Überprüfung Verdacht schöpfen. Zumal ja die ERGEBNISSE (also Treffer) von Suchfragen ohnehin und überhaupt nicht protokolliert werden. **]
*] Als Beispiel zu verstehen, nicht als Hinweis darauf, wie phonetische Algorithmen in bestimmten Datenbanken tatsächlich arbeiten!
**] Nur INPOL-Z führt auch ein Protokoll der Ergebnisse mit, die eine spezifische Suche durch einen Benutzer ***] an einem bestimmten Tag ergeben hat. Dieses Protokoll unterliegt jedoch einer sehr strikten Zweckbindung und ist nur unter sehr eingeschränkten Bedingungen vom BKA zu erhalten.
***] Dieser Tage wurde in mehreren Zeitungsartikeln der Eindruck erweckt, als sei der Benutzer einer INPOL-Suche immer anhand eines persönlichen Namens / seiner Kennung zu identifizieren. Das mag so sein für die Benutzer IM BKA. Es trifft nicht zu für alle Benutzer aus anderen Polizeibehörden zu. Diese arbeiten häufig mit einer Art ‚Sammelkennung‘ für die jeweilige Behörde. Aus dem INPOL-Protokoll ist dann nur noch erkennbar, aus welcher Behörde diese Suche durchgeführt wurde aber nicht mehr von welchem individuellen Nutzer.
Ansätze von „KI“ in polizeilichen Informationssysteme, die mit Intelligenz wenig zu tun haben: Die Kreuztrefferei
In den letzten Jahren hat sich der Trend verstärkt, den Polizeibeamten als ein Wesen zu behandeln, das extremen Schutz benötigt und dem eigenes Denken weitgehend erspart werden soll. Aus dieser Geisteshaltung entsprangen dann Funktionen in polizeilichen Informationssystemen, wie die so genannten Kreuztreffer-Algorithmen. Sie wurden zum Beispiel in integrierten Vorgangs- und Landesauskunftssystemen, wie ViVA in Nordrhein-Westfalen ****] realisiert.
****] ViVA und POLIKS gehören zur gleichen Systemfamilie, entwickelt von T-Systems.
Die Denkweise der Entwickler dieser Kreuztreffer-Algorithmen scheint wie folgt gewesen zu sein:
- Ausgangssituation: Der Polizeibeamte ist dabei, eine Suchfrage zu formulieren: Er sucht den „Thomas“ (Vorname) „Müller (Nachname) geboren irgendwann 1989 („**1989“). [D]
- Alarm, intern, im Suchsystem (ViVA/POLIKS)! Vielleicht hat das suchende Wesen ja nicht nur das, sondern noch was ganz anderes gemeint?! Ihm muss daher geholfen werden! Der Kreuztreffer-Algorithmus wird also aktiv – automatisch im Hintergrund und häufig, ohne dass dies dem Nutzer bewusst ist. Als Ergebnis der Suchfrage sieht der Nutzer dann nicht nur die Personen, die – nach den Angaben in ihrer Führungspersonalie ***** – in 1989 geboren wurden und Thomas Müller heißen. Die Kreuztrefferei präsentiert ihm auch noch sonstige Personen, zum Beispiel einen Thomas Stochowski, der mit GEBURTSnamen Müller hieß und 1989 geboren wurde. Oder einen Dennis Klever, der 1989 geboren wurde und der auch unter dem Aliasnamen Thomas Müller in Erscheinung getreten ist
*****] Eine Führungspersonalie ist das Set aus Personendaten (Namen, Geburtsnamen, Geburtsdatum, -ort und –land), unter dem eine Person in INPOL gespeichert ist. Es ist die Personalie, die für eine Person als ERSTE angelegt wurde, nicht zwangsläufig auch die rechtmäßige Personalie für diesen Menschen.
Anwender von ViVA berichteten, dass dieses Systemverhalten für sie vollkommen intransparent ist. Und den erheblichen Nachteil hat, dass die Suche MEHR scheinbare Ergebnisse liefert, anstatt durch gezieltes Suchen die Zahl der Treffer/Ergebnisse immer mehr einzuengen.
Protokollierung von Datenbankabfragen
Weit verbreitet ist die Ansicht, dass die Abfragen von polizeilichen Datenbanken protokolliert werden. Und dass bei Kontrollen hinterher festgestellt werden kann, welcher Beamte wann welche Datenbanken befragt hat UND welche Ergebnisse er zu sehen bekam. Diese Ansicht ist falsch! In fast jeder Hinsicht!
Rechtsgrundlage für die Protokollierung
Ausdrückliche Anforderungen an die Protokollierung von Verarbeitungsvorgängen in polizeilichen Informationssystemen sind relativ neu: Erst die so genannte JI-Richtlinie *** ***] gibt Mindeststandards vor für die Verarbeitung personenbezogener Daten durch Sicherheitsbehörden und -darunter eben auch – deren Protokollierung. Ihre Vorgaben bilden, gemeinsam mit der Datenschutzgrundverordnung (DSG-VO), seit 2018 den gemeinsamen Datenschutzrahmen in der Europäischen Union.
Die Umsetzung der JI-Richtlinie für die Polizeibehörden ist den Bundesländern vorbehalten. Dass es da, z.B. bezüglich der Protokollierung, länderspezifische Regelungen gibt, macht der folgende Vergleich deutlich:
*** ***] “Richtlinie (EU) 2016/680 des Europäischen Parlamentes und des Rates vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten durch die zuständigen Behörden zum Zwecke der Verhütung, Ermittlung, Aufdeckung oder Verfolgung von Straftaten oder der Strafvollstreckung sowie zum freien Datenverkehr und zur Aufhebung des Rahmenbeschlusses 2008/977/JI des Rates
Vergleich der Vorschriften zur Protokollierung: JI-Richtlinie, Datenschutzgesetz für Nordrhein-Westfalen und Hessisches Datenschutzgesetz
In der folgenden Tabelle sehen Sie ein praktisches Beispiel dafür, was die JI-Richtline „eigentlich“ vorgibt und was daraus – Unterschiedliches – in nur zwei Landesgesetzen herauskommt:
| JI-Richtlinie, Artikel 25 | NRW, DSG NRW, §55 | Hessen, HDSIG, §71 |
| (1.1) Die Mitgliedstaaten sehen vor, dass in automatisierten Verarbeitungssystemen zumindest die folgenden Verarbeitungsvorgänge protokolliert werden: Erhebung, Veränderung, Abfrage, Offenlegung einschließlich Übermittlung, Kombination und Löschung. | (1.1) (1) In automatisierten Verarbeitungssystemen haben Verantwortliche und Auftragsverarbeiter mindestens die folgenden Verarbeitungsvorgänge zu protokollieren: 1. Erhebung, 2. Veränderung, 3. Abfrage, 4. Offenlegung einschließlich Übermittlung, 5. Kombination und 6. Löschung | (1.1) wie NRW |
| (1.2) Die Protokolle über Abfragen und Offenlegungen müssen es ermöglichen, die Begründung, das Datum und die Uhrzeit dieser Vorgänge und so weit wie möglich die Identifizierung der Person, die die personenbezogenen Daten abgefragt oder offengelegt hat, und die Identität des Empfängers solcher personenbezogenen Daten festzustellen. | (2) Die Protokolle über Abfragen und Offenlegungen müssen es ermöglichen, die Begründung, das Datum und die Uhrzeit dieser Vorgänge und so weit wie möglich die Identität der Person, die die personenbezogenen Daten abgefragt oder offengelegt hat, und die Identität des Empfängers der Daten festzustellen. | (2) wie NRW |
| (2) Die Protokolle werden ausschließlich zur Überprüfung der Rechtmäßigkeit der Datenverarbeitung, der Eigenüberwachung, der Sicherstellung der Integrität und Sicherheit der personenbezogenen Daten sowie für Strafverfahren verwendet. | (3) Die Protokolle dürfen ausschließlich für die Überprüfung der Rechtmäßigkeit der Datenverarbeitung durch die behördliche Datenschutzbeauftragte oder den behördlichen Datenschutzbeauftragten, die Landesbeauftragte für Datenschutz und Informationsfreiheit oder den Landesbeauftragten für Datenschutz und Informationsfreiheit und die betroffene Person sowie für die Eigenüberwachung, für die Gewährleistung der Integrität und Sicherheit der personenbezogenen Daten und für Strafverfahren verwendet werden. | (3) Die Protokolle dürfen ausschließlich zur Überprüfung der Rechtmäßigkeit der Datenverarbeitung durch die Datenschutzbeauftragte oder den Datenschutzbeauftragten und die Hessische Datenschutzbeauftragte oder den Hessischen Datenschutzbeauftragten sowie zur Eigenüberwachung, der Sicherstellung der Integrität und Sicherheit der personenbezogenen Daten und für Strafverfahren verwendet werden. |
| — | (4) Die Protokolldaten sind am Ende des auf deren Generierung folgenden Jahres zu löschen./td> | — |
| (3) Der Verantwortliche sowie der Auftragsverarbeiter stellen die Protokolle der Aufsichtsbehörde auf Anforderung zur Verfügung. | (5) Der Verantwortliche und der Auftragsverarbeiter haben die Protokolle der oder dem Landesbeauftragten für Datenschutz und Informationsfreiheit auf Anforderung zur Verfügung zu stellen. | (4) Wie NRW |
Wer ist verantwortlich für die Protokollierung?
Die JI-Richtlinie und daraus abgeleitete (behördenindividuelle) Rechtsvorschriften definieren zwei Rollen, nämlich den „Verantwortlichen“ und den „Auftragsverarbeiter“:
Verantwortlicher
Das ist laut Definition in der JI-Richtlinie
Auftragsverarbeiter
Hinweis am Rande: Unklar ist, wer im Fall von Hessendata eigentlich der Verantwortliche und wer der Auftragsverarbeiter ist: Denn die Herstellerfirma von Hessendata = Palantir wurde dort ja mit dem BETRIEB des Systems beauftragt: Müssen dann entsprechende Protokollanforderungen in Zukunft an Palantir Technologies GmbH gerichtet werden?
In der Praxis ist es also so, dass der Auftragsverarbeiter sich darum zu kümmern hat, DASS Protokolle erstellt werden.
Wie entstehen diese Protokolle?
Nun ja – technisch gesagt – automatisiert: Im Datenbanksystem sorgt eine Überwachungsinstanz („Trigger“) dafür, dass ein Eintrag in eine Protokolltabelle geschrieben wird, wenn ein Anwender eine der genannten Aktivitäten ausführt. Die Erstellung der Protokolle ist insofern unbestechlich und schwer zu manipulieren.
Allerdings sind diese Protokolle nicht das, was zur Auswertung z.B. an die Datenschutzaufsichtsbehörde übergeben wird. Auch ist es nicht üblich, dass sich die Aufsichtsbehörde diese Protokolle selbst aus der/den entsprechenden Protokolltabelle(n) besorgt. Vielmehr selektiert ein Mitarbeiter des Auftragsverarbeiters Auszüge aus den Protokollen und stellt für die Auswertung diesen Auszug, z.B. in Form einer Excel-Liste, zur Verfügung.
Die haben den Nachteil, dass bei der Erstellung der Liste Information unabsichtlich verloren gegangen sein kann. Oder absichtlich unter den Tisch fiel. Mit der Folge, dass die zur Auswertung übergebene Excel-Protokollliste de facto NICHT vollständig wiedergibt, was tatsächlich im System abgefragt, geschrieben oder verändert wurde. Um wirklichen Beweischarakter zu erlangen, müsste also überprüft werden, ob die zur Auswertung bereit gestellten Listen mit den Rohprotokollen inhaltlich übereinstimmen und ob sie genauso vollständig sind, wie die Rohprotokolle …
Was steht in diesen Protokollen?
Nutzer-Aktivitäten sollen protokolliert
Nach der JI-Richtlinie und den darauf aufsetzenden Gesetzen sollen diese Aktivitäten protokolliert werden: 1. Erhebung, 2. Veränderung, 3. Abfrage, 4. Offenlegung einschließlich Übermittlung, 5. Kombination und 6. Löschung. Diese Aktivitäten definieren also den Anlass für einen Protokolleintrag.
Beispiele dafür, dass bestimmte Aktivitäten bisher nicht protokolliert werden
Nur am Rande sei bemerkt, dass die drei letztgenannten Aktivitäten meinem Eindruck nach bisher überhaupt nicht protokolliert werden.
Beispiel Übermittlung: Sonst hätte es ja nicht geschehen können, damls 2017 beim G20-Gipfel, dass die Berliner Polizei nicht sagen konnte, dass sie bestimmte (belastende) Informationen über Journalisten an das BKA übermittelt hatte. Die bei der Berliner Polizei dann längst gelöscht waren. Aber dennoch beim BKA verzeichnet blieben und für den Ausschluss einzelner Journalisten während des G20-Gipfels führten [F].
Anderes Beispiel: Kombination = Zusammenführung von Datensätzen [C]: Diese Anforderung steht auch im Datenschutzgesetz von Nordrhein-Westfalen. Einen Protolleintrag über die Zusammenführung der Datensätze des Syrers Amad A. und des Maliers Amedy G. war bei den bisher öffentlich gewordenen Ergebnis der Ermittlungen jedoch noch kein Thema.
Und die Löschung: Hat Ähnlichkeiten mit einem Henne-Ei-Problem: Wie und wo soll gespeichert werden, was gelöscht wird, wenn doch gelöscht worden ist … ???
Übliche Informationen in solchen Protokollen
Darüber hinaus finden sich in solchen Protokollen üblicherweise diese Informationen:
- ein Datums-/Zeitstempel
- Kennung, ggf. ergänzt um den Namen des Nutzers bzw. Bezeichnung der Organisationseinheit, dem/der diese Kennung zugewiesen ist,
- ggf. Bezeichnung des Arbeitsplatzrechners, der für die Abfrage genutzt wurde,
- Suchkriterien, die in der Abfrage verwendet wurden, bei Personen also insbesondere (und wahlweise nutzbar) Familienname, Vorname, Geburtsdatum, Geburtsname (nicht gesetzlich vorgeschrieben!)
- Angaben zum Zweck / Grund der Abfrage
- sowie eine Angabe darüber, welche Datenquellen abgefragt wurden, also z.B. INPOL oder SIS (Schengen Informationssystem) oder das behördeneigene Vorgangsbearbeitungssystem oder das Ausländerzentralregister usw. (in Systemen, die es erlauben, mit EINER Suchfragemehrere Zieldatenbanken abzufragen).
Wer hat die Abfrage getätigt?
Kennung und Passwort dienen zur Identifikation des Nutzers bei der Protokollierung von Aktivitäten. Das erfüllt bei einem personifiziert vergebenen Kennung/Passwort auch den beabsichtigten Zweck. Im Protokoll steht dann die „Identifikation“ für die jeweilige Nutzer-Person.
Anders dagegen bei funktionsspezifischen Sammelkennungen: Dann steht im Protokoll nur eine Funktionsbezeichnung, z.B. „LKA-Servicekennung“ (frei erfunden). Die kann zum jeweiligen Zeitpunkt von mehreren Personen genutzt worden sein. Funktionsspezifische Kennungen / Passwörter machen es damit faktisch unmöglich, im strafrechtlichen Sinne exakt die individuelle Zurechenbarkeit einer (illegalen) Datenbankabfrage festzustellen. Was später zur Folge haben kann, dass im Protokoll einer verdächtigen Datenbankabfrage der Nutzer mit dem ersten Logon verzeichnet ist. Der aber sagt, dass er’s nicht war … Und damit läuft die Möglichkeit, die illegale Abfrage einem bestimmten Nutzer zuzuordnen ins Leere – und das Strafverfahren ist einzustellen.
Aufbewahrungsfrist für die Protokolle
In der JI-Richtlinie konnte ich keine Vorschriften finden für die Dauer der Aufbewahrung solcher Protokolle. Nordrhein-Westfalen ist in diesem Pukt über die JI-Richtlinie hinausgegangen und hat vorgeschrieben, dass „Protokolldaten am Ende des auf deren Generierung folgenden Jahres zu löschen“ sind.
Das ist ein ziemlich enger Zeitrahmen, wie der Fall des Syrers Amad A. zeigt, der – unschuldig auf der Grundlage der Haftbefehle für einen ganz anderen Mann – in Haft genommen wurde und nach einem Brand in seiner Zelle verstorben ist [A, B]. Das war 2018. 2019 kam ein Ermittlungsverfahren der Staatsanwaltschaft gegen Polizeibeamte in Gang, ebenso ein parlamentarischer Untersuchungsausschuss. Der arbeitet im Jahr 2020 immer noch. Die Protokolle über Aktivitäten in den NRW-Polizeidatenbanken, die der Inhaftierung von Amad A. im Juli 2018 vorausgingen, konnten nach dieser Vorschrift jedoch schon Ende 2019 gelöscht werden. Belastende bzw. entlastende Beweise für Verantwortlichkeiten von Mitwirkenden an dieser Inhaftierung wären nach dieser Gesetzeslage nicht mehr vorhanden.
Pflichtangabe zum Zweck der Abfrage
Diese Angabe ergibt sich aus dem Konzept der Zweckbindung. Es besagt, dass Informationen in einer Polizeidatenbank nur zu dem Zweck verwendet werden sollen, zu dem sie erhoben und gespeichert wurden. *** ****] Dass und wie sehr damit Schindluder getrieben werden kann, hatten wir im Teil 2 dieser Serie bereits beschrieben.
*** ****] Eine Aufweichung dieses Konzepts, d.h. nachträgliche Änderung und Verwendung einer Information auch zu anderen Zwecke, ist inzwischen vorgesehen und greift immer mehr um sich.
Besitz, Nutzung und Auswertung solcher Protokolle
Wenn dann die Notwendigkeit des Nachermittelns solcher Abfragen besteht, wird die Sache ziemlich kompliziert. Das zeigen aktuell die Fälle der illegalen Datenbankabfragen durch Polizisten in Hessen oder die Ermittlung der Umstände, die zum Tod des Syrers Amad A. in der JVA Kleve führten.
Enge Zweckbestimmung für die Nutzung der Protokolle
Weil die oben wiedergegebenen Rechtsvorschriften ganz klar einen ZWECK FÜR DIESE PROTOKOLLE vorgeben:
- Sie dürfen „ausschließlich zur Überprüfung der Rechtmäßigkeit der Datenverarbeitung,
- der Eigenüberwachung,
- der Sicherstellung der Integrität und Sicherheit der personenbezogenen Daten,
- sowie für Strafverfahren“
verwendet werden.
Diesen Zweck wird der Besitzer dieser Protokolle, praktisch also der Datenschutzbeauftragte des Auftragsverarbeiters, genau prüfen, bevor er die Protokolle auch tatsächlich herausgibt.
Enger Empfängerkreis für die Protokolle
Eng ist auch der Nutzer- bzw. Empfängerkreis für diese Protokolle und im Gesetztext abschließend geregelt. Ein parlamentarischer Untersuchungsausschuss kommt darin nicht vor. Das lässt sich aus dem PUA III (Kleve / AmadA) im Landtag NRW lernen und sollte Aspiranten auf Einsetzung eines Untersuchungsausschuss im hessischen Landtag ebenfalls zu denken geben.
Auftragsverarbeiter sind nicht zwangsläufig unabhängig-objektive Instanz, wenn es um Datenschutzverletzungen geht
Die o.g. Auftragsverarbeiter sind – in manchen Polizeiorganisationen mehr, in anderen weniger – auch die Verantwortlichen für die Entwicklung, Pflege und Weiterentwicklung der verwendeten polizeilichen Informationssysteme.
Um ein Beispiel zu nennen: Das Landesamt für Zentrale Polizeiliche Dienste in Nordrhein-Westfalen (LZPD) ist Auftraggeber für die Pflege und Weiterentwicklung von ViVA – des integrierten Vorgangsbearbeitungs- und INPOL-Land-Systems in Nordrhein-Westfalen. In dieser Rolle hat das LZPD erst im Dezember 2019 einen Auftrag für die Pflege, Wartung und Weiterentwicklung von ViVA über 27.7 Mio Euro an die Herstellerfirma T-Systems vergeben.
Das System ViVA, um das es im Fall des Syrers Amad A. geht, soll fehlerhaft gearbeitet haben. Das sagte sogar der Innenminister [B]. Aufgrund eines „Kreuztreffers“ (so die offiziellen Lesart, getragen von der Regierungsmehrheit) sei der ViVA-Datensatz des Syrers Amad A. mit dem ViVA-Datensatz eines per Haftbefehl gesuchten Maliers namens Amedy G. zusammengeführt worden [C]. Das völlig unterschiedliche Aussehen der beiden Personen und ihre ganz andere Vita ist angeblich keinem der daran beteiligten Polizeimitarbeiter aufgefallen. Diese Zusammenführung der zwei Datensätze in ViVA hatte zur Folge, dass Amad A. zur Vollstreckung der Ersatzfreiheitsstrafe des Maliers – ohne weitere richterliche Überprüfung – in Haft verblieb, bis es zu dem Brand in seiner Zelle kam. An dessen Folgen verstarb der junge Mann einige Tage später.
Es gibt – aus der Auswertung mehrere Protokolle zu diesem Vorgang, die ich vornehmen konnte [A, B, E] – erhebliche Zweifel an dieser Darstellung. Die konnte ich – gegen zeitweilige und lautstarke Unmutsbekundungen von Mitgliedern der Regierungsfraktion – auch im Untersuchungsausschuss des Landtages NRW vortragen. Danach wurde das LZPD, also der Verantwortliche für die Entwicklung, wartung und Pflege des inkriminierten Systems ViVA (und LKA) mit einem Gutachten beauftragt. Und kam – so die Darstellung in der Presse – dass an diesen, meinen Ergebnissen angeblich „nichts dran“ sei. Auf die Inhalte dieses Gutachtens möchte ich hier und heute nicht eingehen.
Jedoch die Frage aufwerfen: Ist es nicht ein erheblicher Konstruktionsfehler, wenn die Verantwortlichen für die Protokollierung von Aktivitäten in einem polizeilichen Informationssystem (hier also Mitarbeiter des LZPD) gleichzeitig Verantwortliche sind für das IT-System, das ganz offen von der Landesregierung beschuldigt wird, den Fehler erst verursacht zu haben?! Jeder Mensch mit gesundem Menschenverstand nennt eine solche Konstruktion: Den Bock zum Gärtner machen …
Der zweifelhafte Beweischarakter solcher Protokolle
In der gerade dargestellten Situation war der Auftragsverarbeiter LZPD sowohl der Verantwortliche für die Entwicklung und den Betrieb des (angeblich) fehlerhaften IT-Systems als auch der Ersteller der (entlastenden) Protokolle. Welche objektive, unabhängige, weitere Instanz überprüft solche Protokolle und stellt sicher, dass die vorgelegten Protokoll-Exzerpte – sie liegen im Ergebnis dann als Excel-Listen vor – auch tatsächlich lückenlos und vollständig sind?
Die Staatsanwaltschaft hat dazu erfahrungsgemäß nicht die notwendigen Spezialisten. Ein parlamentarischer Untersuchungsausschuss – wie im Fall PUA III in NRW von einer Mehrheitsfraktion mit vorgefertigter (politischer) Intention bestimmt, kommt nicht zu einem Beschluss für eine Überprüfung der vorgelegten Beweise. Die Polizei – politisch abhängig vom Innenministerium selbst – ist auch nicht der beste Kandidat, um gegen den eigenen technischen Dienstleister zu ermitteln. Der ebenfalls abhängig ist vom gleichen Innenminsterium.
Wer also sollte in solchen Situationen für objektive Klarheit sorgen? Und wie kann sichergestellt werden, dass die dazu notwendigen Belege – Protokolle also – nicht zuvor manipuliert wurden, weil der zum Protokollführung verpflichtete Auftragsverarbeiter gleichzeitig auch verantwortlich ist für die u.U. fatalen Fehler des von ihm betriebenen Systems?
Vernachlässigte Meldepflichten bei Datenschutzverletzungen
In Artikel 30 der JI-Richtlinie und in daraus abgeleiteten Ländergesetzen ist folgendes verpflichtend vorgesehen: Wenn es zu einer Verletzung des Schutzes von personenbezogenen Daten kommt – z.B. aufgrund von Datenbankabfragen / Datendiebstahl – für die es keine dienstlichen Gründe gab – so hat der Verantwortliche der Datenschutzaufsichtsbehörde darüber binnen 72 Stunden Mitteilung zu machen. Es sei denn, dass die Verletzung des Schutzes personenbezogener Daten voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Wenn die Meldung an die Aufsichtsbehörde nicht binnen 72 Stunden erfolgt, so ist ihr eine Begründung für die Verzögerung beizufügen.
Das setzt voraus, dass die „Verantwortlichen“ überhaupt regelmäßige Kontrollen vornehmen, ob illegale Datenbankabfragen oder andere Varianten von Datendiebstahl vorkommen. Ob und in welchem Umfang solche Kontrollen vorgenommen werden, lässt sich nicht sagen. Von einzelnen Polizeibehörden, z.B. Hessen und Berlin, wurde bekannt, dass sie jede z.B. 200. Abfrage prüfen. Dabei scheint aber im Vordergrund zu stehen, ob der Zweck der Abfrage ausreichend konkret angegeben ist. Es kann der Eindruck aufkommen, dass die genannte Meldepflicht auch dadurch umgangen werden kann, dass nur sehr zurückhaltend Kontrollen durchgeführt werden.
Der Hamburger Datenschutzbeauftragte sagt zur Erfüllung der Meldepflicht in seinem Tätigkeitsbericht für 2019:
Bei drei von fünf dem HmbBfDI in 2019 durch die Polizei Hamburg gemeldeten Data Breaches ist eine den Anforderungen des Gesetzes entsprechende Meldung nicht in der vorgesehen Frist von 72 Stunden erfolgt. …“
Fazit
Die oben dargestellten möglichen Tricksereien bei der Abfrage von Polizeidatenbanken, die eklatanten Mängel bei der Protokollierung, ein alles andere als überbordender Kontrolleifer bei den Verantwortlichen für polizeiliche Datenbanken und Meldepflichten, die großzügig falsch ausgelegt werden, weisen darauf hin, dass die aktuell bekannt gewordenen, missbräuchlichen Abfragen von Polizeidatenbanken und Datenbanken anderer Behörden, die für Polizeibeamte erreichbar sind, nur die Spitze des Eisbergs darstellen.
Alle Artikel der Serie ‚Abfragen von Datenbanken durch Polizeibeamte‘
Teil 1: Besondere Rechte und Pflichten der Polizeibeamten bei der Abfrage von Polizeidatenbanken und Datenbanken anderer Behörden
Abfrage von Polizeidatenbanken -1: Polizeibeamte und Datenbanken
Teil 2: Arbeitsplätze, Zugangskontrollen und die Wirksamkeit von Angaben zum Zweck der Abfrage
Abfrage von Polizeidatenbanken -2: Zugangskontrolle und Zweck der Abfrage
Teil 3: Suchfragen und trickreiche Möglichkeiten; Protokollierung von Abfragen und was daraus NICHT zu erkennen ist
Abfrage von Polizeidatenbanken -3: Suchoptionen und Protokollierung
Quellen
[1] Droht der Berliner Polizei ein Datenschutz-Skandal?, 20.08.2018, Tagesspiegelhttps://www.tagesspiegel.de/berlin/sicherheitsluecken-im-polizei-system-droht-der-berliner-polizei-ein-datenschutz-skandal/22933306.html
Verwandte Beiträge
[A] Ergebnisse technischer Auswertungen zum Fall des Syrers Amad Ahmad (A.A.) / JVA KleveWie Manipulationen in INPOL den Syrer A.A. hinter Gitter brachten … [B] NRW-Innenminister Reul beantwortet Fragen im Landtag zur Namens-Verfälschung im Falle des Syrers A. A.
Wenn der Minister berichtet … [C] Anmerkungen zur Zusammenführung von Datensätzen in polizeilichen Informationssystemen
Personen und Identitäten – in Datenbanken der Polizei und in der Wirklichkeit [D] Ihr erhöhtes Risiko, wenn Sie Müller bzw. Thomas heißen UND in einer Großstadt geboren sind
Vom Kreuztreffer getroffen [E] Heureka! Die Software ist schuld!
Probleme mit Kreuztreffern im NRW-Polizeisystem ViVA [F] Informationsgenerierung und Erkenntnisgewinnung im polizeilichen Staatsschutz
Wie Journalisten zu Gewalttätern (gemacht) werden
Copyright und Nutzungsrechte
(C) 2020 CIVES Redaktionsbüro GmbH
Sämtliche Urheber- und Nutzungsrechte an diesem Artikel liegen bei der CIVES Redaktionsbüro GmbH bzw. bei dem bzw. den namentlich benannten Autor(en). Links von anderen Seiten auf diesen Artikel, sowie die Übernahme des Titels und eines kurzen Textanreißers auf andere Seiten sind zulässig, unter der Voraussetzung der korrekten Angabe der Quelle und des/der Namen des bzw. der Autoren. Eine vollständige Übernahme dieses Artikels auf andere Seiten bzw. in andere Publikationen, sowie jegliche Bearbeitung und Veröffentlichung des so bearbeiteten Textes ohne unsere vorherige schriftliche Zustimmung ist dagegen ausdrücklich untersagt.