Den Schutz vor Angreifern und Malware hat sich IT-Administrator im März auf die Fahnen geschrieben. So lesen Sie in der Ausgabe, mit welchen Handgriffen Sie ... (mehr)

Get in the Ring: Konflikte

Die tatsächlichen Konflikte treten durch die beschriebenen unterschiedlichen Sichtweisen und Zielsetzungen auf. Es könnte also passieren, dass ein Berechtigungskonzept aus Datenschutzsicht eine klare Rollentrennung nach Aufgaben vorsieht, wobei aus ISB-Sicht diese Rollentrennung vielleicht nicht zwingend notwendig ist, da die zugreifenden Personen aufgrund ihrer Hierarchieebenen ausreichend autorisiert sind.

Auch die Datensparsamkeit kann problematisch werden. Kontrovers ist dieses Schutzziel zum Beispiel dann, wenn es sich um Zugriffsdaten von Mitarbeitern in den Protokollen eines Proxy-Servers handelt. Die Speicherdauer eines solchen Protokolls würde von einem Datenschutzbeauftragten möglichst kurz und von einem ISB möglichst länger festgelegt werden. Auch die inhaltliche Gestaltung von Systemprotokollen birgt Konfliktpotenzial. Der ISB möchte natürlich alle relevanten Informationen speichern, der Datenschutzbeauftragte wird vorschlagen, dass alle Personenbezüge möglichst außen vor bleiben und nur die wirklich erforderlichen Daten gespeichert werden.

Die Datensparsamkeit hat aber auch einen zeitlichen Bezug. Sie betrifft die Löschfristen für Daten. Der DSB wird darauf achten, dass personenbezogene Daten zum frühestmöglichen Zeitpunkt gelöscht werden. Das heißt, dass die Löschung dann stattfindet, wenn der Verarbeitungszweck erreicht ist und keine rechtliche Grundlage für ein weiteres Aufbewahren der Daten besteht. Auch hier kann es sein, dass die Organisation oder der Sicherheitsbeauftragte eine längere Speicherdauer vorsehen möchten, weil diese Daten noch irgendwann einmal gebraucht werden könnten.

Auch bei der Verfügbarkeit ist die Umsetzung häufig konfliktträchtig. Das Schutzziel der Verfügbarkeit aus der Sicht der Informationssicherheit befürwortet eine redundante Speicherung von Daten. Redundanz bewirkt, dass ein technischer Defekt keinen Datenverlust bedeuten muss. Für den Datenschutzbeauftragten bedeutet Redundanz jedoch, dass es viele, aus Datenschutzsicht meist unnötige, Speicherorte gibt, die alle eine potentielle Gefährdung für die betroffenen Personen darstellen. Er wird fordern, dass sorgfältig abgewogen wird, ob weitere Speicherorte zulässig sind.

Die Konsequenzen der unterschiedlichen Sichtweisen der IS und des DS wird an folgendem Beispiel besonders deutlich. Nehmen wir an, der Administrator des Unternehmens hat den Auftrag, eine Speicherlösung in der Cloud auszuwählen. Er befolgt die Unternehmensrichtlinien der Informationssicherheit und wählt den Dienstleister nach den internen Vorgaben aus. Der Dienstleister sitzt in den USA und betreibt weltweit Rechenzentren, die alle entsprechend zertifiziert sind. Wirtschaftlich und technisch ist der Dienstleister nachweislich geeignet. Der ISB ist zufrieden, denn die Vorgaben der Organisation wurden eingehalten. Aus Sicht des ISB hat der Administrator alles richtig gemacht. Der DSB jedoch bemängelt, dass gesetzliche Vorgaben verletzt werden. Der Dienstleister betreibt seine Rechenzentren an Standorten auf der Welt, an denen ein ausreichendes Datenschutzniveau nicht gewährleistet ist. Es fehlen die vom Gesetzgeber geforderten zusätzlichen Garantien, um die personenbezogenen Daten der Betroffenen adäquat zu schützen. Die Vorgaben, nach denen der Administrator den Dienstleister ausgesucht hat, waren nicht vollständig. Die Organisation hatte es versäumt, die Regeln für die Auswahl des Dienstleisters auch datenschutzkonform zu gestalten. Der Administrator hat alles richtig gemacht, die Organisation nicht.

Fazit

Wenn der ISB und der DSB einzeln ihre Konzepte, Richtlinien und Vorgaben entwickeln, ohne gemeinsam über den konkreten Sachverhalt zu sprechen, kann es sein, dass einander widersprüchliche Vorgaben in der Organisation entstehen. Der Administrator, der die Vorgaben umsetzen soll, steht vor dem Konflikt, dass er nicht weiß, welche die richtige ist.

Der Gesetzgeber sieht vor, dass der Datenschutzbeauftragte keine Weisungsbefugnis hat. Deshalb liegt es an der Geschäftsführung zu regeln, wer die tatsächlich auszuführenden Maßnahmen zum Schutz der Datenverarbeitung vorgibt. Das kann der ISB oder die IT-Leitung sein. Denn dort liegen die organisatorischen Verantwortlichkeiten. Da die Fäden beim Administrator zusammenlaufen, hat er aus seiner Position die Möglichkeit, entsprechende Konflikte zwischen Datenschutz und Informationssicherheit zu erkennen und alle Beteiligten darauf aufmerksam zu machen.

Grundsätzlich gilt: Für die Informationssicherheit werden betriebliche Entscheidungen getroffen, in denen Risiko und Nutzen einander abgewogen werden. Beim Datenschutz gibt es konkrete gesetzliche Vorgaben. Innerhalb dieser Vorgaben ist der Spielraum für Entscheidungen weitaus geringer als in der Informationssicherheit. Im Zweifel stellt die eine Entscheidung aus Sicht des ISB nur ein wirtschaftlich kalkulierbares Risiko dar, aus Sicht des Datenschutzes möglicherweise einen Gesetzesverstoß, der eine Ordnungswidrigkeit darstellt.

Wenn der Administrator solche Konflikte erkennt, sollte er alle Beteiligten an einen Tisch holen und miteinander ins Gespräch bringen. Nur wenn der DSB und der ISB sich in der Sache austauschen, lässt sich eine tragfähige und gesetzlich konforme Lösung finden. Ohne aufmerksame Administratoren wird eine solche Chance verpasst. Und das sollte auch jede Geschäftsführung wissen.

(jp)

comments powered by Disqus
Mehr zum Thema

Stukturierte Informationssicherheit

IT-Sicherheit – oder besser Informationssicherheit – gilt immer noch als ein rein technisches Thema, angesiedelt bei der IT-Abteilung. Lange Zeit war das sicherlich auch der Fall. Eine rein technische Absicherung reicht heutzutage jedoch nicht aus, und eigentlich hat sie es auch noch nie getan. Vielmehr ist es wichtig, dass technische und organisatorische Maßnahmen ineinandergreifen und zum Schutz der Unternehmenswerte beitragen. Ein gelebtes Informationssicherheits-Managementsystem soll Organisationen  bei solchen Aufgaben unterstützen.

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019