Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

6    Systemdatenschutz

6.1          Landesebene

6.1.1       Zusammenarbeit mit dem Zentralen IT-Management (ZIT SH) und weiteren IT-Stellen

Basisdiensteverordnung und Zentrale-Stelle-Basisdiensteverordnung
Das Zentrale IT-Management der Landesregierung Schleswig-Holstein (ZIT SH) betreibt zentral und federführend Basisdienste für die Landesverwaltung und teilnehmende weitere Verwaltungen, beispielsweise zentrale Portale und Nutzerkonten im Rahmen der OSI-Plattform, Bezahlsysteme und Portale zur Entgegennahme elektronischer Rechnungen. Diese können durch die sogenannten beteiligten Stellen genutzt werden. Details dazu sind in der Basisdiensteverordnung (BasisdiensteVO) und insbesondere in deren Anlage geregelt. Diese Verordnung wird flankiert von der Zentrale-Stelle-Basisdiensteverordnung (ZStBaDiVO), die die datenschutzrechtlichen Verantwortlichkeiten zwischen dem ZIT SH und den beteiligten Stellen regelt, etwa zur Dokumentation, zu Umsetzung von Rechten betroffener Personen oder bei der Meldung von Datenschutzvorfällen gemäß Artikel 33 und 34 DSGVO.

Wie in den vergangenen Berichtszeiträumen war das ULD als Gast in der Konferenz der IT-Beauftragten (ITBK) und den Koordinierungsrunden der IT-anwendenden Behörden beteiligt und wurde dort über aktuelle und geplante IT-Projekte informiert. Anders als in den Vorjahren gab es im Berichtszeitraum weniger Einbindungen in konkrete Verfahren oder in Regelwerke, die im Rahmen der Mitbestimmung entstanden und eine landesweite Bedeutung haben.

Eine formelle Beteiligung im Rahmen von Stellungnahmen und Anhörungen zu Verordnungsentwürfen und zu Nutzungsvereinbarungen für IT-Verfahren erfolgte u. a. zur Erweiterung von Basisdiensten in der Basisdiensteverordnung.

Auch mit anderen IT-Stellen des Landes gibt es eine Zusammenarbeit, beispielsweise mit dem Amt für Informationstechnik (AIT) und im Bereich des Bildungsministeriums.

Schwerpunkte sind hier die gegenseitige Information und die Abklärung von Grundsatzfragen eines datenschutzgerechten IT-Einsatzes, insbesondere im Vorfeld der Einführung neuer Verfahren.

Was ist zu tun?
Die frühzeitige Information und Einbindung des ULD sollte fortgesetzt bzw. wieder intensiviert werden.

 

6.1.2       Einsatz von KI im Landesbereich – Sachstandserhebung

Am 14. April 2022 wurde das „Gesetz über die Möglichkeit des Einsatzes von datengetriebenen Informationstechnologien bei öffentlich-rechtlicher Verwaltungstätigkeit“ (IT-Einsatz-Gesetz – ITEG) im Gesetz- und Verordnungsblatt für Schleswig-Holstein 2022 veröffentlicht.

Ein datengetriebener Ansatz im Zusammenhang mit automatisierten Verarbeitungstätigkeiten bedeutet zunächst allgemein, dass ein Fachverfahren Entscheidungen trifft, die auf der Analyse und Interpretation von Daten basieren. Im allgemeinen Sprachgebrauch werden diese Verfahren auch als KI-Systeme (KI: künstliche Intelligenz) bezeichnet.

Der wesentliche Grundsatz des Gesetzes betrifft die Zuverlässigkeit des Einsatzes von datengetriebenen Informationstechnologien: Jede öffentliche Stelle stellt „… die Transparenz, Beherrschbarkeit, Robustheit und Sicherheit der von ihr eingesetzten, datengetriebenen Informationstechnologien durch geeignete technische und organisatorische Maßnahmen sicher“ (§ 2 Abs. 1 ITEG). Dabei soll die Zuordnung in die drei verschiedenen Automationsstufen

• Assistenzsysteme,
• Delegation,
• autonome Entscheidung

als Grundlage dienen, die Risiken zu beurteilen und geeignete technische und organisatorische Maßnahmen zur Gewährleistung der Sicherheit auszuwählen.

„Für den Einsatz von datengetriebenen Informationstechnologien und dessen Folgen sowie die Beachtung der Vorgaben dieses Gesetzes ist die öffentliche Stelle verantwortlich, die diese Technologien zur Erledigung der ihr übertragenen Aufgaben einsetzt“ (§ 4 Abs. 1 ITEG). Sie muss

• im Sinne der Transparenz den Algorithmus der datenbasierten Informationstechnologien und die diesem zugrunde liegende Datenbasis offenlegen (§ 6 Abs. 1),
• zur Gewährleistung der Beherrschbarkeit umso umfangreichere Maßnahmen ergreifen, je höher die Automationsstufe der datengetriebenen Informationstechnologie ist (z. B. Vorrangmöglichkeit menschlicher Entscheidungen vor automatisierten Entscheidungen und Korrektionsmöglichkeiten automatisierter Entscheidungen (§ 9 Abs. 1 ITEG)),
• die Robustheit von datengetriebenen Informationstechnologien in Bezug auf unerwünschte oder unerlaubte Veränderungen bzw. Manipulation gewährleisten (§ 10 ITEG) und
• die Sicherheit datengetriebener Informationstechnologien durch Maßnahmen sicherstellen, die dem Stand der Technik sowie dem Schutzbedarf entsprechen. Das betrifft sowohl die Datenbasis als auch die beteiligten Daten, Systeme und Prozesse (§ 6 Abs. 2 ITEG).

Verantwortliche führen ein Verzeichnis aller Verarbeitungstätigkeiten (Artikel 30 DSGVO) in ihrer Zuständigkeit. Kommen datengetriebene Informationstechnologien zum Einsatz, dann müssen die Angaben nach Artikel 30 DSGVO um weitere Angaben ergänzt werden, um eine ausreichende Transparenz gemäß ITEG zu erreichen. Dazu gehören z. B.

• Zuordnung der datengetriebenen Informationstechnologie zu einer Automationsstufe in einer gesonderten Erklärung,
• Offenlegung des Algorithmus von datenbasierten Informationstechnologien sowie der zugrunde liegenden Datenbasis sowie eine Beschreibung der grundsätzlichen Funktionsweise und die Entscheidungslogik des Algorithmus in einer allgemein verständlichen Sprache,
• Erstellung einer Handreichung für Betroffene, wenn Entscheidungen auf die „teilweise oder vollständige Bearbeitung und gegebenenfalls Entscheidungsfindung mittels datengetriebener Informationstechnologien“ basieren.

Ergänzend fordert § 6 Abs. 2 ITEG, dass datengetriebene Informationstechnologien, die keine personenbezogenen Daten verarbeiten, ebenfalls in einem Verzeichnis analog zu Artikel 30 DSGVO geführt werden.

Die öffentlichen Stellen sollten weiterhin beachten, dass vor einem erstmaligen Training oder dem erstmaligen Einsatz von datengetriebenen Informationstechnologien eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO (bei der Verarbeitung personenbezogener Daten) bzw. eine Technik-Folgenabschätzung (sofern keine personenbezogenen Daten verarbeitet werden) durchgeführt werden muss. Auch diese Folgenabschätzungen sind mit Dokumentationspflichten versehen.

Das ULD wird eine exemplarische Erhebung der Verarbeitungsverzeichnisse von datengetriebe-
nen Informationstechnologien starten, um einen Überblick über den Einsatz von datengetriebenen Informationstechnologien in den Behörden in Schleswig-Holstein zu erhalten. Diese Erhebung soll sich (in zeitlichen Abschnitten) über alle Verwaltungsebenen erstrecken.

Das ULD wird anhand der Ergebnisse, die diese Erhebung liefert, die Verbreitung von datengetriebenen Informationstechnologien in öffentlichen Stellen in Schleswig-Holstein und deren technische und organisatorische Einbindung in die behördliche Datenverarbeitung bewerten. Dabei liegt das Hauptaugenmerk darauf, ob Betroffene ihre Rechte (Betroffenenrechte) wirksam ausüben können und inwieweit sie durch Transparenzmaßnahmen der öffentlichen Stelle über ihre Rechte informiert werden.

 

6.1.3       Sicherheitskonzepte mit SiKoSH

Bereits seit einigen Jahren beteiligt sich das ULD am Projekt SiKoSH des ITV.SH. Ziel dieses Projektes ist es, Kommunen und kleinere Organisationen dabei zu unterstützen, die an sie gestellten Anforderungen an Informationssicherheit umzusetzen (36. TB, Tz. 6.1).

Dazu lehnt sich das Projekt stark an die Vorgaben des IT-Grundschutzes des BSI an und fasst die für kommunale Datenverarbeitung typischen Aspekte zusammen. Ein wichtiger Aspekt im ITGrundschutz ist die Flexibilität, Sicherheitsvorgaben für viele denkbare Situationen zu machen – je nach Größe der Organisation, ihrer Geschäftsprozesse, eingesetzter Soft- und Hardware, genutzter Dienstleister bis hin zum Steuerungs- und Organisationsmodell. Der „Preis“ dieser Flexibilität ist die Verpflichtung, organisationsinterne Vorgaben mithilfe von Richtlinien, Anweisungen und Konzepten zu entwerfen und diese umzusetzen.

SiKoSH
SiKoSH (Sicherheit für Kommunen in Schleswig-Holstein) ist ein Projekt, um Kommunen und kleineren Organisation beim Aufbau eines Informationssicherheitsmanagements zu unterstützen.

ITV.SH
Der IT-Verbund Schleswig-Holstein (ITV.SH) wird von den Kommunen des Landes Schleswig-Holstein getragen. Seine Aufgaben sind u. a., verwaltungsübergreifende Projekte zu realisieren.

BSI
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat mit dem IT-Grundschutz einen Standard geschaffen, der das Management der Informationssicherheit sowie konkrete Sicherheitsmaßnahmen beschreibt. Insbesondere die öffentliche Hand orientiert sich an diesem Standard und ist teilweise auch gesetzlich verpflichtet, ihn umzusetzen.

Dieser erste Schritt der Steuerung, nämlich der Entwurf zentraler Dokumente, fällt schwer, wenn man bislang noch gar nicht mit dem Thema befasst war. Andererseits gibt es im kommunalen Bereich häufig vergleichbare Situationen hinsichtlich der internen Organisation und Zuständigkeiten, der IT-Ausstattung und der eingesetzten Soft- und Hardware. Daher liegt es nahe, sich bei dem Entwurf solcher Dokumente an Vorlagen zu orientieren und bei guten Vorlagen „abzugucken“.

An dieser Stelle setzt SiKoSH mit der Bereitstellung von Musterdokumenten an. Zwar müssen sie an die jeweilige Situation vor Ort angepasst werden, geben aber ein gutes Gerüst vor und haben viele Aspekte integriert – dies ist für diejenigen wichtig, die bisher nur wenig Kontakt zum IT-Grundschutz hatten.

Ein zweiter Aspekt ist eine Priorisierung von Sicherheitsmaßnahmen: In der Theorie kann man nicht genug davon haben, um auf alle denkbaren Fälle vorbereitet zu sein. In der Praxis konzentriert man sich auf die relevanten Maßnahmen, um das Risiko eines Sicherheitsvorfalls auf ein akzeptables Maß zu reduzieren. Ebenso ist es häufig notwendig, bei der Umsetzung zu priorisieren: Beispielsweise ist es aus Sicherheitssicht zwar wichtig, dass in einem Zutrittskontrollsystem auch das Betriebssystem der Chipkarten gegen Hackerangriffe geschützt sind – doch solange Türen und Fenster unverschlossen sind, liegt in diesem Punkt eine größere Gefahr, dass Unbefugte ein Gebäude oder IT-Räume betreten.

Für vergleichbare Situationen und IT-Strukturen gibt es im IT-Grundschutz die Möglichkeit, Maßnahmenbündel in sogenannten Profilen zusammenzufassen und hierbei Prioritäten vorzugeben. Ziel ist dabei, konzeptionelle Arbeiten „vor die Klammer zu ziehen“ und die Ergebnisse auch anderen Organisationen zur Verfügung zu stellen. Zusätzliche Sicherheitsmaßnahmen sind immer möglich.

Das IT-Grundschutz-Profil „Basis-Absicherung Kommunalverwaltung“ ist hier abrufbar:

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Profile/Basis_Absicherung_Kommunalverwaltung.html
Kurzlink: https://uldsh.de/tb41-6-1-3

Das ULD beteiligt sich an dem Projekt SiKoSH, um die Sicherheitsanforderungen des Datenschutzes (u. a. Vorgaben aus dem Artikel 32 DSGVO) und spezifische Dokumentationsvorgaben (z. B. zu Test und Freigabe) mit einfließen zu lassen. Dies ist bei der Sicherheitsanforderung auf der Ebene der Infrastruktur und der zentralen Konzepte (z. B. dem Pachtmanagement) vergleichsweise einfach. Werden die Anforderungen jedoch spezifischer (etwa bei der Umsetzung in Fachverfahrenssoftware) oder umfassen sie Aspekte, die die Informationssicherheit (zunächst) nicht im Fokus hat (etwa Pseudonymisierung, Datensparsamkeit, Löschfristen oder Funktionalitäten zur Umsetzung vor den Rechten Betroffener gemäß Artikel 12-23 DSGVO), so müssen diese Anforderungen zusätzlich betrachtet werden.

Da das prinzipielle Vorgehen (Analyse, Risikobetrachtung, Maßnahmenauswahl, Implementierung und Kontrolle) im Bereich Datenschutz große Ähnlichkeiten zum Vorgehen im Informationssicherheitsmanagement hat, liegt der Gedanke nahe, beide Vorgehensweisen zu integrieren – bis dahin, eine Person mit beiden Aufgaben (Informationssicherheitsbeauftragte und Datenschutzbeauftragte) zu betrauen.

In größeren Organisationen ist Letzteres nicht zu empfehlen: Zum einen gibt es genügend Aufgaben für mehrere Personen. Zum anderen gibt es teilweise gegenläufige Interessen zwischen Datenschutz und Informationssicherheit, etwa im Bereich der Protokollierung oder des Beschäftigtendatenschutzes, die gegeneinander abzuwägen sind. Hierbei ist eine unabhängige Sicht wichtig – eine konstruktive Zusammenarbeit und die Nutzung von Synergien, etwa bei der Dokumentation, sind hingegen ausdrücklich gewünscht.

Das Ziel der Beauftragung mehrerer Personen lässt sich in kleineren Organisationseinheiten nicht immer umsetzen. Während die Beauftragungen einer oder eines Datenschutzbeauftragten in Behörden gesetzliche Pflicht ist, ist dies bei Informationssicherheitsbeauftragten meist nicht der Fall. Wenn die Alternative darin besteht, keine Person mit der Bearbeitung von Informationssicherheitsfragen zu betrauen, ist eine Doppelbeauftragung die sinnvollere Alternative.

Was ist zu tun?
Das Thema Informationssicherheit ist auch für den Datenschutz wichtig. Mit SiKoSH ist insbesondere für kleinere Organisationen ein Einstieg in dieses Thema möglich.

 

6.1.4       Arbeitskreis IT der Rechnungsprüfungsämter

Schon seit vielen Jahren beteiligt sich das ULD, wie auch der Landesrechnungshof, am „Arbeitskreis IT der Rechnungsprüfungsämter der Kreise und der Städte Schleswig-Holsteins“.

Beschäftigte der Rechnungsprüfungsämter sind auch mit dem Thema IT-Prüfung befasst. Meist liegt der Fokus im Bereich der Beschaffung und Vergabe. Bei der IT-Prüfung geht es auch um den ordnungsgemäßen Einsatz von IT. Dies schließt neben weiteren Vorgaben auch Fragen des Datenschutzes sowie der Informationssicherheit (auch jenseits der Verarbeitung personenbezogener Daten) ein. Daher sind die IT-Prüferinnen und Prüfer an den Vorgaben und Prüfmaßstäben interessiert, die die Datenschutzaufsichtsbehörde und der Landesrechnungshof anwenden.

Innerhalb der Kreise und der Städte arbeiten Rechnungsprüfungsamt und Datenschutzbeauftragte meist eng zusammen und sind teilweise in Personalunion tätig – auch dies erklärt das Interesse des Arbeitskreises am Thema Datenschutz. So werden bei den halbjährlichen Treffen des Arbeitskreises häufig auch Detailfragen an uns herangetragen. Diese Treffen sind daher eine gute Gelegenheit, diese zu beantworten, miteinander ins Gespräch zu kommen, Informationen auszutauschen und auch aus übergeordneten Gremien zu berichten.

Für den Arbeitskreis bietet sich die Gelegenheit, zusammen tätig zu werden und lokale Prüfungen und Sachstandserhebungen gemeinsam zu entwerfen und auszuwerten. Dabei kann die Arbeitslast der Konzeption auf mehrere Schultern verteilt und Doppelarbeit vermieden werden. Für das ULD ist wichtig, dass die behördlichen Datenschutzbeauftragten an den Ergebnissen teilhaben, soweit es Datenschutzaspekte betrifft. Es spricht auch nichts gegen ihre Mitwirkung bei der Prüfungsgestaltung.

Was ist zu tun?
Die bisherige gute Zusammenarbeit sollte fortgesetzt und für Synergien genutzt werden.

 

6.2          Deutschlandweite und internationale Zusammenarbeit der Datenschutzbeauftragten

6.2.1       Neues aus dem AK Technik

Der AK Technik ist der Arbeitskreis der Datenschutzaufsichtsbehörden des Bundes und der Länder, der sich mit technischen Fragestellungen beschäftigt. Ihm gehören zusätzlich als Gäste u. a. auch Vertreter des Datenschutzes aus den Bereichen Kirchen und Rundfunk an; daneben gibt es Kontakte in das deutschsprachige Ausland.

Ein wichtiges Thema des Arbeitskreises ist das Standard-Datenschutzmodell (SDM), das in einer Unterarbeitsgruppe entwickelt wird (Tz. 6.2.2). Der AK Technik ist hier die erste Freigabeinstanz. Die weitere Arbeit des Arbeitskreises war im Berichtszeitraum stärker als sonst von der Zuarbeit zu Dokumenten anderer Arbeitskreise geprägt.

Dies betrifft zunehmend auch Dokumente auf europäischer Ebene: In der europäischen Technology Subgroup, einer Arbeitsgruppe des Europäischen Datenschutzausschusses (EDSA) zu Technikaspekten, gibt es Vertretungen einzelner EU-Staaten, so auch aus einzelnen Aufsichtsbehörden in Deutschland. Deren Aufgabe ist es, die Sicht der deutschen Aufsichtsbehörden in Europa zu vertreten und umgekehrt die europäische Sicht nach Deutschland zu transportieren. Auf fachlicher Ebene erfolgt dies im AK Technik, der hier wie ein Spiegelgremium agiert.

Im Berichtszeitraum wurden insbesondere Dokumentenentwürfe zu Pseudonymisierung und Anonymisierung diskutiert; ein wichtiges Dokument des Vorjahres waren Leitlinien zu Datenpannenmeldungen gemäß Artikel 33 DSGVO. Die Arbeit ist besonders wichtig, wenn es sich bei den Dokumenten um sogenannte Leitlinien des EDSA handelt: Diese dienen der europaweiten einheitlichen Interpretation der DSGVO und anderer europäischer Datenschutzregelungen und wirken einerseits als Orientierungshilfen nach außen, entfalten aber im Hinblick auf die Datenschutzbehörden eine gewisse Bindungswirkung. Daher ist eine sorgfältige Formulierung und Betrachtung der zahlreichen nationalstaatlichen Besonderheiten wichtig, denn das Autorenteam auf europäischer Ebene deckt nicht alle Staaten ab.

 

6.2.2       Standard-Datenschutzmodell 3.0

Das Standard-Datenschutzmodell (SDM) wurde unter der Leitung des ULD überarbeitet. Die Überarbeitung war notwendig, um der zentralen Stellung von „Verarbeitung“ und „Risiken“ in der DSGVO besser als bislang gerecht zu werden. Die wesentlichen Modellkomponenten wurden in der Grafik „SDM-Würfel“ zusammengezogen mit dem Ziel, auf einen Blick alle wesentlichen Risiken einer Verarbeitung zu erfassen und diese analysieren zu können.

Der neu erstellte Abschnitt D2.1 „Aufbereitung einer Verarbeitungstätigkeit in Vorgänge oder in Phasen eines Datenlebenszyklus“ empfiehlt, bei Verarbeitungen mit hohem Risiko zumindest neun Vorgänge zu unterscheiden. Für weniger riskante Verarbeitungen kann dagegen die Unterscheidung in vier unterschiedliche Phasen des Lebenszyklus eines Datums – von der Kollektion der Daten über deren Bereithaltung, deren Nutzung und Beseitigung – ausreichen. Die Darstellung einer Verarbeitung in Vorgänge oder Phasen stellt vor Augen, dass bei der Erhebung von Daten z. B. andere Risiken bei der Sicherung der Vertraulichkeit als bei der Nutzung oder der Beseitigung von Daten bestehen und entsprechend abgestimmte Schutzmaßnahmen bestimmt und implementiert werden müssen. Die Auffächerung legt außerdem den Gedanken nahe zu prüfen, ob die bestehenden Rechtsgrundlagen alle Vorgänge bzw. die vier Phasen jeweils ausreichend abdecken.

Der Abschnitt D2.2 „Ebenen einer Verarbeitung oder Verarbeitungstätigkeit“ verweist darauf, bei einer Verarbeitung außerdem noch drei Ebenen einer Verarbeitung zu unterscheiden. Dadurch geraten ebenenspezifische Risiken in den Blick. Die Ebene 1 entspricht dem, was abstrakt unter einem „Fachverfahren“ und „Geschäftsprozess“ mit einem bestimmten funktionalen Ablauf verstanden wird. Das ist die Ebene, in der die Logik einer Verarbeitung im Zentrum der Betrachtung steht, ohne dass auch schon die dafür verwendete Technik beachtet werden muss. Wesentlich für die datenschutzrechtlich angemessen funktionale Gestaltung dieser Ebene ist die Bestimmung des Zwecks einer Verarbeitungstätigkeit, dessen Bindung auf den beiden nachfolgenden Ebenen sichergestellt werden muss.

Abbildung: "SDM-Würfel"

Vier Risikotypen im Datenschutz
Risikotyp A: Der Grundrechtseingriff bei natürlichen Personen durch die Verarbeitung ist nicht hinreichend milde gestaltet.

Risikotyp B: Die Maßnahmen zur Verringerung der Eingriffsintensität einer Verarbeitung sind in Bezug auf die Gewährleistungsziele nicht vollständig oder werden nicht hinreichend wirksam betrieben oder nicht in einem ausreichenden Maße stetig kontrolliert, geprüft und beurteilt.

Risikotyp C: Die Maßnahmen, die nach der Informationssicherheit geboten sind (vgl. z. B. IT-Grundschutz nach BSI), sind nicht vollständig oder werden nicht hinreichend wirksam betrieben oder werden nicht in einem ausreichenden Maße stetig kontrolliert, geprüft und beurteilt.

Risikotyp D: Die Maßnahmen der Informationssicherheit werden nicht ausreichend datenschutzgerecht im Sinne des Risikotyps A und Risikotyps B betrieben.

Auf der Ebene 2 ist die zweckgemäße praktische Umsetzung der Verarbeitung angesiedelt. Diese umfasst zum einen die Sachbearbeitung sowie die Fachapplikation(en). Ebene 3 umfasst die ITInfrastruktur, die Funktionen für die IT der Ebene 2, typisch in Form von Rechenzentrumsdiensten, zur Verfügung stellt.

Der ebenfalls neu erstellte Abschnitt D2.5 „Überblick über die Modellierungstechniken des SDM („SDM-Würfel“)“ stellt die neun Verarbeitungsvorgänge bzw. vier -phasen, die drei Ebenen und die sieben Gewährleistungsziele des SDM in einen grafischen Zusammenhang. Jeder kleine Würfel aus dem Gesamtwürfel steht für ein aus der DSGVO abgeleitetes Risiko für die Rechte und Freiheiten einer Person, das bei einer Verarbeitung zu betrachten und grundsätzlich zu verringern ist. Der „SDM-Würfel“ entwirft insofern ein sinnvolles Gesamtbild der zu bearbeitenden Datenschutzrisiken von Verarbeitungstätigkeiten (siehe „SDM-Würfel“).

Das bereits in der Version SDM-V2 enthaltene Kapitel D3 „Risiken und Schutzbedarf“ wurde um eine Risikotypologie erweitert, wonach vier Risikotypen zu unterscheiden sind. Diese Typologie ist wortgleich im Abschnitt „CON.2 – Datenschutz“ des IT-Grundschutz-Kompendiums 2023 des BSI (Bundesamt für Sicherheit in der Informationstechnik) enthalten. Es ist mit dem BSI abgesprochen, dass IT-Grundschutz und SDM bei gegenseitigen Verweisen explizit auf einen gemeinsamen Anker für das Verständnis von Datenschutzrisiken zurückgreifen können.

 

6.2.3       Microsoft 365 – aktuelle Entwicklungen der Arbeitsgruppe

Im Herbst 2020 wurde eine Arbeitsgruppe der Datenschutzkonferenz (DSK) mit dem Auftrag eingesetzt, im Austausch mit Vertreterinnen und Vertretern von Microsoft die Vertragsunterlagen für den Einsatz von Microsoft 365 zu prüfen und datenschutzgerechte Nachbesserungen zu erreichen. Diskutiert und am Ende bewertet wurde insbesondere der Datenschutznachtrag, zuletzt in der Aktualisierung vom 15. September 2022. Durch die notwendige Eingrenzung erfolgten keine technischen Untersuchungen über tatsächliche Datenflüsse, keine Untersuchungen über die tatsächlichen Verarbeitungen, keine Prüfung von Einzelkomponenten sowie keine vollständige datenschutzrechtliche Bewertung des Dienstes anhand des gesamten Vertragswerks von Microsoft.

Microsoft 365
Der vom US-amerikanischen Unternehmen Microsoft angebotene Online-Dienst Microsoft 365 (ehemals Office 365) beinhaltet die Online-Versionen von Office-Anwendungen wie Word oder Excel sowie weitere Webanwendungen. Mit Microsoft 365 kann ortsunabhängig und von jedem unterstützten Endgerät aus gearbeitet werden. Die Daten befinden sich in Rechenzentren von Microsoft.

Bereits mit diesem engen Fokus konnte die DSK jedoch unter Bezugnahme auf den Bericht der Arbeitsgruppe feststellen, „dass der Nachweis von Verantwortlichen, Microsoft 365 datenschutzrechtskonform zu betreiben, auf der Grundlage des von Microsoft bereitgestellten ‚Datenschutznachtrags vom 15. September 2022‘ nicht geführt werden kann“. Besonders herausgehoben wurde die mangelnde Transparenz über die Verarbeitung von personenbezogenen Daten und dass Microsoft Daten zu eigenen Zwecken verwendet, die nicht klar beschrieben und eingegrenzt sind.

Die Arbeitsgruppe hat in zwei Jahren gemeinsamer Arbeit und intensivem Austausch mit Ansprechpartnerinnen und Ansprechpartnern der Microsoft Deutschland GmbH sowie der Microsoft Corporation in 14 mehrstündigen Videokonferenzen diverse Fragestellungen diskutiert, die sich aus einer Bewertung des AK Verwaltung der DSK im Jahr 2020 und aus den gemeinsamen Gesprächen ergeben haben.

Festlegung der DSK und Berichte der Arbeitsgruppe
Die Arbeitsgruppe hat einen umfangreichen Bericht über die Untersuchungen erstellt und der DSK vorgelegt. Die beschlossene Festlegung der DSK wurde zusammen mit einer Zusammenfassung des Berichts veröffentlicht.

Festlegung der DSK:
https://datenschutzkonferenz-online.de/media/dskb/2022_24_11_
festlegung_MS365.pdf
Kurzlink: https://uldsh.de/tb41-6-2-3a

Zusammenfassung des Berichts:
https://datenschutzkonferenz-online.de/media/dskb/2022_24_11_
festlegung_MS365_zusammenfassung.pdf
Kurzlink: https://uldsh.de/tb41-6-2-3b

Kurzlink zum freigegebenen Gesamtbericht:
https://uldsh.de/tb41-6-2-3c

In mehreren Themenbereichen konnten keine signifikanten Verbesserungen erreicht werden, beispielsweise bei der Festlegung von Art und Zwecken der Verarbeitung sowie der Art der personenbezogenen Daten, sodass der Gegenstand der Auftragsverarbeitung noch nicht spezifisch und detailliert genug beschrieben ist. Ähnlich fehlen bei der Verarbeitung „für legitime Geschäftsinteressen“ von Microsoft noch klare vertragliche Grenzen und mehr Informationen darüber, welche Daten Microsoft zu welchen Geschäftszwecken verarbeitet. Gleiches gilt für Telemetrie- und Diagnosedaten, deren Nutzung für eigene Zwecke von Microsoft ebenfalls unklar bleibt.

Demgegenüber konnten durch die Gespräche Verbesserungen bei der Information von Verantwortlichen über Unterauftragsverarbeiter erreicht werden. Auch die Verlagerung der Datenverarbeitung in die EU wird grundsätzlich begrüßt. Weitere Schritte sind aber notwendig, damit Verantwortliche mit geringerem Aufwand Microsoft 365 auch wirklich datenschutzkonform einsetzen können.

Was ist zu tun?
Verantwortliche müssen den Einsatz von Microsoft 365 eigenständig prüfen und nachweisen können, dass ihre Verarbeitungsprozesse datenschutzkonform sind. Dieser Nachweis kann nicht allein mithilfe der Unterlagen von Microsoft erbracht werden. In den Berichten der DSK werden zum Teil Möglichkeiten aufgezeigt, die allerdings kundenspezifische vertragliche Konkretisierungen erfordern.

 

6.2.4       Taskforce Souveräne Cloud

Schon seit vielen Jahren nimmt die Nutzung von Cloud-Dienstleistungen zu. Nutzen Verantwortliche oder Auftragsverarbeiter solche Dienstleistungen, so geben sie einen großen Teil der Aufgaben ab, die zum Betrieb einer technischen Infrastruktur notwendig sind. Gleichzeitig fallen damit Steuerungsmöglichkeiten weg.

Dieser Effekt steigt mit der Spezialisierung der Cloud-Dienstleistung: Können Cloud-Anwendende bei der Nutzung einer technischen Infrastruktur („Infrastructure as a Service“, beispielsweise Hardware und Netzanbindung) noch weitgehend selbst über Betriebssysteme, Datenbanken und Anwendungssoftware bestimmen, ist dies am anderen Ende des Spektrums bei der Nutzung bereitgestellter Software („Software as a Service“) nur sehr eingeschränkt möglich: Hier geben die Cloud-Anbieter die Software bis hin zur eingesetzten Version vor; Änderungen und Anpassungen sind nur soweit möglich, wie die Konfiguration der angebotenen Software dies zulässt. Darüber entscheidet allein der Cloud-Anbieter.

Diese Erkenntnis ist nicht neu, und bei der privaten Nutzung von Cloud-Diensten haben die meisten Nutzenden solche Einschränkungen schon kennengelernt, besonders bei der Nutzung von Apps. Dies kann auch Datenschutzfragen betreffen, etwa beim Einsatz von Tracking-Tools oder bei der Einbindung von Drittanbietern. Je nach Ausmaß der Änderung und Alternativen reicht die Reaktion dann von Verärgerung bis zum Entschluss, die Apps zu löschen oder durch andere auszutauschen.

Digitale Souveränität
Digitale Souveränität ist in einem umfassenden Sinne „die Summe aller Fähigkeiten und Möglichkeiten von Individuen und Institutionen, ihre Rollen in der digitalen Welt selbstständig, selbstbestimmt und sicher ausüben zu können“.

(„Digitale Souveränität“, Kompetenzzentrum Öffentliche IT (ÖFIT), November 2017)

Für Verantwortliche und Auftragsverarbeiter ist ein solcher Wechsel meist nicht ganz so einfach umsetzbar. An dieser Stelle setzen Projekte an, die sich die digitale Souveränität auf die Fahne geschrieben haben und eine selbstständige, selbstbestimmte und sichere Nutzung der digitalen Welt anstreben. Dies umfasst u. a., dass solche Angebotswechsel aus technischer und rechtlicher Sicht möglich sind. Es bedeutet aber auch, dass Anbieter von Cloud-Dienstleistungen ihrerseits souverän agieren können. Dies schließt auch Fragen der Gesetzgebung ein, denen sie unterliegen – ein ständiger Diskussionspunkt bei Angeboten außerhalb der EU.

Die Taskforce „Souveräne Cloud“ der Datenschutzkonferenz arbeitet derzeit an einem Positionspapier, das diese Fragen aufgreift und als Anforderungen formuliert. Der Blick ist dabei bewusst etwas weiter gefasst als die Frage der aktuellen Einhaltung der Datenschutzregelungen (insbesondere der DSGVO) und beinhaltet auch Aspekte wie

• Nachvollziehbarkeit durch Transparenz,
• Datenhoheit und Kontrollierbarkeit,
• Offenheit,
• Vorhersehbarkeit und Verlässlichkeit,
• geeignete Garantien zum Nachweis der aufgestellten Forderungen.

Ziel ist es, sowohl Cloud-Anwendenden (z. B. Verantwortlichen) als auch Cloud-Anbietern Prüfpunkte für Souveränitätseigenschaften an die Hand zu geben, damit „souveräne Cloud“ nicht nur ein Marketingbegriff ist.

6.3          Ausgewählte Ergebnisse aus Prüfungen, Beratungen und Meldungen nach Artikel 33 DSGVO

6.3.1       E-Rezept – Datenübermittlungen an Patientinnen und Patienten?

Schleswig-Holstein ist neben Westfalen-Lippe eine der Regionen, in denen das elektronische Rezept (E-Rezept) für Versicherte gesetzlicher Krankenkassen praktisch erprobt wird.

Dabei soll der klassische Weg eines Papierrezeptes nachgebildet werden: die Ausstellung in Arztpraxen und die Einlösung durch die Patientinnen und Patienten in einer Apotheke ihrer Wahl. In der Papierwelt ist dies für Arztpraxen vergleichsweise einfach: Rezepte werden auf Papier ausgedruckt und übergeben. Sie enthalten Daten der Patientin oder des Patienten sowie der verordneten Arzneimittel und werden in Apotheken vorgelegt. Im Gegenzug werden die verordneten Arzneimittel ausgegeben; die Apotheken behalten das Rezept und rechnen dann mit der jeweiligen Krankenkasse ab.

E-Rezepte sind technisch gesehen Datensätze, mit dem genau dies ermöglicht werden soll. Anders als Papierrezepte können und sollen sie auch elektronisch übertragen werden. Auf diese Weise kann mancher Gang in die Arztpraxis oder die Apotheke entfallen, und auch die Weitergabe an Angehörige zur Abholung eines Medikamentes wäre einfacher.

Ein Datensatz könnte aber auch kopiert werden, um ihn mehrfach in Apotheken einzulösen. Was in der Papierwelt durch Aufdruck, Stempel, Entwertung und Einbehalten des Rezeptes in der Apotheke erfolgt, muss in der elektronischen Welt nachgebildet werden. Deswegen ist die technische Umsetzung aufwendiger: Arztpraxen erzeugen einen Verordnungsdatensatz (mit Patienten- und Arzneimitteldaten) und legen ihn in einer zentralen Datenbank ab. Patientinnen und Patienten bekommen anstelle des Rezeptes einen sogenannten Token (ein kleiner Datensatz vergleichbar einer Postfach- oder Schließfachnummer), mit dessen Hilfe die Verordnungsdaten aus der Datenbank abgerufen werden können. Der Token wird an die Apotheke übergeben, die den Verordnungsdatensatz aus der Datenbank abruft und bearbeitet – in diesem Augenblick wird der Datensatz gesperrt und eine Doppeleinlösung unterbunden. Ist ein Arzneimittel nicht vorrätig, muss der Datensatz wieder entsperrt werden, damit das Rezept bzw. der Token in einer anderen Apotheke eingelöst werden kann.

Der Zugriff auf die Datenbank ist abgesichert und liegt in der sogenannten Telematikinfrastruktur, an die Arztpraxen, Krankenhäuser und Apotheken über besonders gesicherte Netze angebunden sind. Über die Telematikinfrastruktur und die darin abgebildeten Fachanwendungen werden dann Zugriffsberechtigungen umgesetzt. Im Fall der Apotheken bedeutet dies, dass technisch ein Zugriff auf alle aktuellen elektronischen Verordnungen möglich ist, sofern der entsprechende Token vorliegt.

Telematikinfrastruktur (TI)
Die Telematikinfrastruktur (TI) ist die zentrale Plattform für digitale Anwendungen im deutschen Gesundheitswesen.

Patientinnen und Patienten können auch an die Telematikinfrastruktur angebunden werden, um darüber beispielsweise Zugang zur geplanten elektronischen Patientenakte und auch zu ihren E-Rezepten zu bekommen, um diese (genauer: die dazugehörigen Token) einer Apotheke vorlegen zu können. Da Versicherte erst einmal zuverlässig durch ihre Krankenkasse identifiziert und mit verlässlicher Software angebunden werden müssen (vergleichbar einer Zulassung im Online-Banking), ist diese Anbindung bei Patientinnen und Patienten derzeit nicht weit verbreitet.

Wie sollen Patientinnen und Patienten nun ERezepte bekommen und an Apotheken übertragen, wenn sie nicht über die sichere Anbindung verfügen? Eine Möglichkeit ist ein Papierausdruck ähnlich dem klassischen Rezept, der den Token in Form eines DataMatrix-Codes (ähnlich wie ein QR-Code) enthält. Dieser wird in Apotheken bei der Vorlage des Rezeptes eingescannt und erlaubt dann den Apotheken den oben beschriebenen Abruf der elektronischen Verordnung aus der Telematikinfrastruktur und seine Weiterverarbeitung.

Verständlicherweise ist ein Papierausdruck nicht die Vorstellung, die man von einem elektronischen Rezept und der Möglichkeit, es auch elektronisch zu übertragen, hat. Daher wurde die Idee geboren, den Token an Patientinnen und Patienten per E-Mail zu übertragen. Diese E-Mail kann dann, beispielsweise auf einem Smartphone, in Apotheken vorgelegt und der enthaltene DataMatrix-Code eingescannt werden.

An das ULD wurde nun im Sommer 2022 von der Kassenärztlichen Vereinigung (KVSH) die Frage herangetragen, ob der Versand der Token per EMail datenschutzrechtlich unproblematisch sei – er enthalte ja nicht die Daten der Verordnung (Patientendaten und Arzneimittel), sondern sei lediglich ein Zugriffsschlüssel, mit dem Teilnehmende an der Telematikinfrastruktur, also insbesondere Apotheken, die Verordnungsdaten abrufen könnten. Werde eine solche E-Mail abgefangen oder kopiert, könnten Unbefugte mit dem Token die Rezeptdaten nicht abrufen, da sie keinen Zugriff auf die Telematikinfrastruktur haben. Der Versand des Tokens per E-Mail sei folglich unproblematisch. Anders wäre es, den kompletten E-Rezept-Ausdruck (mit DataMatrix-Code, Versicherten- und Verordnungsdaten) zu versenden, etwa als PDF-Datei: Hier lägen die Daten im Klartext vor – ein Versand des Komplettausdrucks sei unverschlüsselt nicht möglich.

Dieses Argument scheint schlüssig, lässt aber bestimmte Funktionalitäten aufseiten der Apotheken außer Acht: Einige von ihnen bieten Patientinnen und Patienten, beispielsweise über Apotheken-Apps, die Möglichkeit, E-Rezepte einzulösen. Dazu muss der Token des E-Rezeptes an die Apotheke übermittelt werden (z. B. durch Einscannen des DataMatrix-Codes), die dann die Verordnung aus der Telematikinfrastruktur abruft, die Warenverfügbarkeit prüft und Verfügbarkeit und Arzneimittel in der App anzeigt. Vor dieser Anzeige findet aber keine verlässliche Identitätsprüfung statt – im Prinzip können auf diese Weise alle (auch abgefangene oder kopierte) Token mithilfe der App eingescannt und die Arzneimittel der zugeordneten Verordnung sichtbar gemacht werden.

Im Ergebnis ist ein Token ebenso sprechend wie ein Rezept oder ein E-Rezept-Ausdruck, und daher ebenso sensibel. Die Sicherheitsannahme, dass ausschließlich Apotheken die Verordnung zu einem Token auslesen können, ist durch die Bereitstellung der Apotheken-Apps nicht mehr tragfähig. Von einer unverschlüsselten Versendung per E-Mail hat das ULD daher abgeraten.

Unabhängig von der Tatsache, dass das E-Rezept zumindest mit Papierausdrucken und der Nutzung der (wenig verbreiteten) Patienten-App pilotiert werden könnte, hat die KVSH die Teilnahme am E-Rezept-Pilotversuch vorerst gestoppt.

Gematik
Die Gematik ist die Nationale Agentur für Digitale Medizin. Als Koordinierungsstelle für Interoperabilität setzt sie Standards und trägt die Gesamtverantwortung für die Telematikinfrastruktur (TI), betreibt sie aber technisch nicht selbst.

Die Gematik arbeitet derzeit an einer Spezifikation, mit der Apotheken nur anhand von Daten der Versichertenkarte, die bei einer Abholung vorgelegt werden müsste, die Verordnungsdaten abrufen – sozusagen die Versichertenkarte als Ausweis. Aber auch hier stellen sich Fragen, die in der Papierwelt einfach zu beantworten sind: Wie können Patientinnen und Patienten, die zeitgleich mehrere Verordnungen bekommen haben, entscheiden, welche Verordnung durch welche Apotheke abgerufen werden kann? Dies kann durchaus eine Rolle spielen, wenn Verordnungen bei verschiedenen Apotheken oder auch gar nicht eingelöst werden sollen. Und ist sichergestellt, dass Daten aus den Versichertenkarten nicht unbefugt gespeichert und für weitere Abrufe ohne Wissen und Wollen der Versicherten genutzt werden?

Zusammenfassend lässt sich feststellen, dass es zahlreiche Detailprobleme gibt, aber auch widerstreitende Interessen: Aus medizinischer Sicht wird eine Gesamtschau auf Gesundheitsdaten präferiert mit der Folge, dass Ärztinnen und Ärzte sowie Apotheken einen Überblick haben, welche Krankheiten mit welchen Medikamenten behandelt werden. Aus Sicht der Patientinnen und Patienten ist häufig eine Selbstbestimmung gewünscht mit der Folge, dass über die Weitergabe von Verordnungsdaten an Apotheken individuell entschieden werden kann. Dies erfordert eine Steuerungsmöglichkeit, deren sichere Umsetzung in der elektronischen Welt deutlich komplexer ist als die Ausgabe eines Stück Papiers. Ebenso erfordert die Möglichkeit, dass Rezepte ohne persönliche Anwesenheit ausgestellt werden sollen (Telemedizin), an Versicherte übertragen werden und von ihnen auch ohne Vorsprache eingelöst werden können (Versandapotheken), entsprechend sichere Kommunikationswege.

All dies betrifft aber nicht nur Schleswig-Holstein, sondern alle Bundesländer. Die Regelungen gelten bundesweit, denn die Spezifikation erfolgt durch die Gematik aufgrund einer Bundesgesetzgebung. Daher gibt es einen engen Austausch mit den anderen Datenschutzaufsichtsbehörden.

Das im Rahmen der Beratung der KVSH versandte Schreiben des ULD vom 19. August 2022, die daraufhin veröffentlichte Presseerklärung der KVSH vom 22. August 2022 sowie die Presseerklärung des ULD vom 23. August 2022 mit weiteren Hinweisen sind unter dem folgenden Link abrufbar:

https://www.datenschutzzentrum.de/artikel/1414-1.html
Kurzlink: https://uldsh.de/tb41-3-6-1

Was ist zu tun?
Bei der Digitalisierung von Prozessen im Gesundheitswesen müssen alle Beteiligten mit ihren Bedürfnissen berücksichtigt werden. Eine Sicherheitsbetrachtung muss übergreifend erfolgen und kann sich nicht auf Sicherheitsannahmen, die für einzelne Verarbeitungsschritte isoliert gelten, verlassen. Wegen der großen Anzahl der Beteiligten (Versicherte, Ärztinnen und Ärzte, Apotheken und andere Leistungserbringer) ist auch damit zu rechnen, dass einzelne Sicherheitsmaßnahmen nicht immer vollständig umgesetzt werden – dies zeigen die Datenpannenmeldungen, die uns vorliegen.

 

6.3.2       Datenpannen im nichtöffentlichen Bereich – alles beim Alten

Im Berichtsjahr 2022 sind aus technischer Sicht keine Schwerpunktverschiebungen der Ereignisse und Vorfälle im Rahmen der Meldungen von Verletzungen des Schutzes personenbezogener Daten (Artikel 33 DSGVO) zu erkennen. Abgesehen von der im Jahr 2021 hervorstechenden Angriffswelle auf die Microsoft-Exchange-Server durch die Hafnium-Hackergruppe verteilen sich die anderen Ursachen der Datenschutzvorfälle nach Artikel 33 DSGVO ähnlich zu diesem Jahr. Die größten Einfallstore zur Erlangung eines nicht autorisierten Zugriffs auf personenbezogene Daten stellen weiterhin Phishing-Attacken und nicht zeitnah geschlossene Sicherheitslücken dar. Die häufig in den Medien dargestellten Erpressungsversuche durch Verschlüsselung von Daten mittels sogenannter Ransomware (Tz. 5.13.2) stellen zumeist nur den letzten Schritt eines Angriffs dar, der mit dem Einstieg durch eines der beiden genannten Einfallstore seinen Ursprung hatte.

Da die Qualität der Phishing-E-Mails und auch der Fake-Webseiten, auf welche die Opfer gelenkt werden, immer besser wird, fallen auch weiterhin viele Menschen darauf rein. Die Bandbreite der von den Angreifern begehrten Zugangsdaten reicht dabei von Postfächern, Online-Banking, Bezahldiensten, Office-Cloud-Diensten und Streaming-Diensten bis zu Verkaufsshops bei Portalen wie eBay oder Amazon. Die Spannbreite der Missbrauchsszenarien ist dabei ebenfalls groß: Missbrauch eines Postfachs zum Versenden von Mails (Spam, Phishing, Schadsoftware), unautorisierte Geldtransfers, Identitätsdiebstahl, Datendiebstahl, unautorisiertes Nutzen von Diensten, Einstellen von Fake-Angeboten in Shops, Erpressung durch Verschlüsselung. Bei allen erfolgreichen Phishing-Angriffen ist zu beachten, dass – unabhängig vom Missbrauchsszenario – Angreifer Vollzugriff auf die Daten hatten und diese zumindest einsehen, vielleicht verändern bzw. löschen oder sogar herunterladen konnten. Daher sind im Fall eines erfolgten Phishing-Angriffs sämtliche Daten zunächst als kompromittiert zu betrachten.

Das zweite Einfallstor zur Erlangung eines nicht autorisierten Zugriffs entsteht durch verspätetes Einspielen von Sicherheitsupdates. Diese Patches werden von den Herstellern von Software bereitgestellt, um bekannte Sicherheitslücken zu schließen. Beim Einsatz von Software müssen die Verantwortlichen sich daher täglich über mögliche Sicherheitsaktualisierungen informieren, Sicherheitswarnungen sichten und mögliche Risiken bewerten. Sollte ein Patch zu einer eingesetzten Software veröffentlicht werden, ist dieser schleunigst einzuspielen. Leider wurde dies von einigen Verantwortlichen nicht beherzigt, sodass Angreifer ausreichend Zeit hatten, das vulnerable System zu finden und die nicht geschlossene Sicherheitslücke auszunutzen. Betroffen waren hier insbesondere E-Mail-Server, Webshops und Content-Management-Systeme. Je nach Größe der Sicherheitslücke kann das versäumte Einspielen eines Patches verheerende Folgen haben.

Phishing & Fake-Webseiten
Als „Phishing“ bezeichnet man Versuche Unbefugter, mittels gefälschter Webseiten (Fake-Webseiten) oder E-Mails Zugangsdaten und Passwörter zu erlangen. Dabei werden Betroffene dazu veranlasst, Zugangsdaten auf Systemen einzugeben, die unter der Kontrolle von Angreifenden stehen.

Wie ist den beiden Einfallstoren beizukommen? Um das Risiko eines erfolgreichen Phishing-Angriffs zu verringern, sind zwei Maßnahmen hervorzuheben: Sensibilisierung und Zwei-Faktor-Authentifizierung. Die Sensibilisierung der Mitarbeiterschaft in Bezug auf schadhafte EMails sollte zum grundsätzlichen Schulungsangebot eines jeden Unternehmens gehören. In regelmäßigen Abständen ist das Personal über neue Phishing-Kampagnen zu informieren, am besten mit beispielhaften Bildern und Angaben, wie betrügerische Absichten zu erkennen sind. Viele Anbieter von Online-Diensten, insbesondere im Bezahl- und Bankingsektor, aber auch bei Office-Clouds und Shops bei Amazon und eBay, bieten inzwischen die Möglichkeit, eine Zwei-Faktor-Authentifizierung einzurichten. Diese Option sollte stets in Betracht gezogen werden. Zusätzlich sollte jedes Unternehmen abwägen, ob die Deaktivierung von Makros in der Bürokommunikationssoftware sowie restriktivere Firewallregeln umsetzbar sind, ohne die betrieblichen Tätigkeiten zu beeinträchtigen. Solche Maßnahmen helfen, automatisierte Angriffe zu erschweren.

Das zeitnahe Schließen von Sicherheitslücken sollte eigentlich ein Standardprozess im IT-Sicherheitsmanagement sein. Wie die Datenpannenmeldungen aber zeigen, gibt es dabei in vielen Unternehmen Optimierungsbedarf. Dies gilt ebenso für das Monitoring der IT-Systeme und des Netzverkehrs sowie für die anschließenden Informations- und Meldewege. Häufig werden bei der Auswertung von Protokolldaten nach einer Datenpanne charakteristische Einträge zu ungewöhnlichen Prozessen und unbefugten Tätigkeiten gefunden, die auf einen Eindringling hinweisen. Da aber entweder kein regelmäßiges Kontrollieren der Protokolldaten stattfand oder entsprechende Warnmeldungen nicht oder verkehrt zugestellt wurden, konnten frühzeitige Gegenmaßnahmen nicht getroffen werden. Auch für diese Sorglosigkeiten gilt: Alles beim Alten!

Was ist zu tun?
Sensibilisierung, sichere Konfiguration und das schnelle Einspielen von Sicherheitspatches helfen, das Risiko von Datenschutzverletzungen durch Phishing einzudämmen und etwaige schädigende Auswirkungen zu begrenzen.

 

Zurück zum vorherigen Kapitel

Zum Inhaltsverzeichnis

Zum nächsten Kapitel