Technische und organisatorische Maßnahmen (TOM)#
Nachfolgend werden einige Aspekte der TOM diskutiert, die das Meldeportal absichern sollen. Dabei werden einige Punkte hervorgehoben, die besonderer Aufmerksamkeit bedürfen.
Es versteht sich von selbst, dass Hersteller und Betreiber solcher Portale den Stand der Technik berücksichtigen. Bei der Frage, was der Stand der Technik ist, helfen oft etablierte Standards wie die Technischen Richtlinien des Bundesamtes für Sicherheit in der Informationstechnik (BSI).
Bei webbasierten Anwendungen sind die Empfehlungen des Projekts OWASP Top Ten gute Mindestanforderungen, um den häufigsten Gefährdungen im Web zu begegnen.
Informationen aus solchen Quellen sollten bei der Umsetzung technischer und organisatorischer Maßnahmen immer berücksichtigt werden.
Falls beim Betrieb des Hinweisgeber-Meldeportals Dienstleister beteiligt sind, wären diese wegen der im System verarbeiteten personenbezogenen Daten per Auftragsverarbeitung nach Art. 28 DS-GVO einzubinden. In diesem Kontext wäre dann eine Prüfung der TOM des Dienstleisters nach Stand der Technik wie bei jeder anderen Auftragsverarbeitung ebenfalls obligatorisch.
Verschlüsselte Kommunikation#
Es ist sowohl im Interesse des Beschäftigungsgebers als auch im Interesse der hinweisgebenden Person, dass unbefugte Dritte keinen Zugriff auf die Kommunikation und die ausgetauschten Informationen erhalten können. Deshalb muss die Kommunikation mindestens auf dem Transportweg verschlüsselt sein. Und die Daten an den Endpunkten dürfen nur befugten Personen zugänglich sein. Zur Konfiguration der Transportverschlüsselung des Servers, der die Kommunikationsendpunkte bedient, sollte die Technische Richtlinie TR-02102-2 des BSI herangezogen werden, die die Vorgaben für die Verwendung von Transport Layer Security (TLS) formuliert. Diese schlägt Protokollversionen für die Kommunikation zwischen Server (Beschäftigungsgeber) und Client (Hinweisgeber) vor, die als sicher gelten. Bei Updates muss beachtet werden, dass nicht nur die jeweilig aktuelle TLS-Version (derzeit Version 1.3) , sondern auch noch als sicher geltende ältere Versionen (derzeit Version 1.2) vom Server angeboten werden.
Der Grund dafür liegt in dem Umstand, dass ein Hinweis von einem privaten Gerät eines Hinweisgebers abgegeben wird, welches vielleicht keine aktuelle Version des Betriebssystems oder der Netzwerksoftware aufweist. Wenn der Server nur die neueste TLS-Version anbietet, würden diese Clients von der Kommunikation ausgeschlossen, was nicht erstrebenswert ist. Durch die immer noch sichere ältere TLS-Version haben auch Clients mit veraltetet Software die Chance, mit dem Server zu kommunizieren. Allerdings müssen alle TLS-Versionen, die als unsicher gelten, abgeschaltet werden.
Server Protokollierung#
Weiter oben wird beschrieben, dass das Meldeportal die Vorgänge im System zur besseren Nachvollziehbarkeit datensparsam protokollieren soll.
Bei einem Einbruch in den Server des Meldeportals, könnten den Tätern die Zugriffsprotokolle in die Hände fallen. Im Sinne eines Hinweisgeberschutzes sollte deshalb die IP-Adresse der hinweisgebenden Person nicht länger als notwendig im Hinweisgebersystem gespeichert werden. Auf eine längerfristige Speicherung muss unbedingt verzichtet werden, um Hinweisgeber nicht unnötig zu gefährden.
Am sichersten wäre es, wenn auf die Speicherung von IP-Adressen vollständig verzichtet würde. Leider ist das aus technischen Gründen nicht möglich. So kann eine Kommunikation zwischen Client und Server nur stattfinden, wenn beide über definierte Endpunkte ihrer Verbindung verfügen, über die der Datenaustausch realisiert wird. Diese Endpunkte, technisch „sockets“ genannt, bestehen zwingend aus der IP-Adresse des Endpunkts und einer Portnummer zwischen 1 und 65535. Ohne die IP-Adresse finden sich die Kommunikationspartner im Netz nicht. Deshalb muss die IP-Adresse des Clients im Meldeportal mindestens für die Dauer der Netzwerkkommunikation im Speicher gehalten werden.
Auch aus einem weiteren Grund kann es erforderlich sein, die IP-Adresse des Clients zu speichern: für das so genannte „Ratelimiting“.
Ratelimiting#
Die Speicherung der IP-Adresse ist deshalb erforderlich, um bestimmte Arten von Angriffen auf das System zu erkennen. So könnte ein Angreifer, um an fremde Meldungen zu gelangen, viele zufällig ausgewählte Nachrichten-ID eingeben. Wenn er Glück hat, kann er durch einen Zufallstreffer eine Nachrichten-ID finden, die zu einer Meldung gehört. So erlangt er Zugang zu der Kommunikation zwischen Hinweisgeber und Beschäftigungsgeber, die mit dieser Nachrichten-ID verknüpft ist.
Eine andere Art des Angriffs ist es, zu versuchen sich mit einem fremden Benutzerkonto anzumelden. Der Angreifer versucht durch Erraten von Benutzernamen und Passwort Zugang zum System zu erhalten.
Solche Angriffe („Brute-Force-Attacken“) können durch die zeitlich gesteuerte Limitierung von Zugriffsmöglichkeiten unterbunden werden („Ratelimiting“). Sensible Bestandteile des Meldeportals, wie die Eingabemaske für Nachrichten-IDs oder Anmeldemasken müssen vor solchen Attacken geschützt werden. Dies geschieht zum Beispiel dadurch, dass die Anzahl der möglichen Aufrufe pro Zeiteinheit beschränkt wird und bei Überschreiten dieser Anzahl zum einen eine Fehlermeldung angezeigt wird und zum anderen der Zugang zur Eingabemaske für eine gewisse Zeitdauer verwehrt wird.
Es könnte beispielsweise festgelegt werden, dass es für die Eingabe einer Nachrichten-ID nur drei fehlerhafte Versuche innerhalb von fünf Minuten möglich sind. Sollten innerhalb von fünf Minuten dreimal falsche Nachrichten-IDs eingegeben werden, wird dem Bediener des Systems angezeigt, dass es zu viele gescheiterte Versuche gab und das System nun für die nächsten fünf Minuten keine Eingabe mehr annimmt. So wird der Angreifer ausgebremst. Intern werden diese Fehlversuche der genutzten IP-Adresse zugeordnet, die für die Zeitdauer der Sperre im System gespeichert werden muss. Nach Ablauf der Sperre kann die IP-Adresse gelöscht werden. Sie wird erst wieder mit dem nächsten Versuch gespeichert, wenn für weitere fünf Minuten wieder drei Versuche eine Nachrichten-ID einzugeben erlaubt werden.
Nachrichten IDs#
Nachrichten-IDs sind zum einen erforderlich, um Nachrichten eindeutig zu identifizieren. Zum anderen aber auch, um Hinweisgebern und Beschäftigungsgebern die anonyme Kommunikation miteinander zu ermöglichen. Durch die Nachrichten-ID finden Hinweisgeber, Meldung und Beschäftigungsgeber zusammen.
Die Nachrichten-IDs sind als Geheimnisse zu betrachten, die von Unbefugten nicht zu erraten sein dürfen. Deshalb ist darauf zu achten, dass bei der Generierung von Nachrichten-IDs der Zufall eine mindestens so große Rolle spielt, dass nach Stand der Technik ein Erraten der ID mit vertretbarem Aufwand nicht möglich ist.
Eine solche Nachrichten-ID könnte eine Kombination von Buchstaben und Ziffern sein, wie beispielsweise „ax53-z644-91me“. Jede der 12 Stellen des Codes kann eines von 36 Zeichen „a“ bis „z“ und „0“ bis „9“ sein. Bei dem vorgestellten Muster von drei Paketen von je vier Zeichen ergeben sich für jede Stelle 36 Möglichkeiten und für alle Stellen zusammen über \(36^{12} = 4,7 * 10^{18}\) Kombinationsmöglichkeiten. Durch die hohe Anzahl an Kombinationsmöglichkeiten ist es für einen Angreifer nahezu unmöglich, eine Nachrichten-ID zu erraten und damit eine Nachricht zu erspähen. Diese hohe Anzahl kombiniert mit den Ratelimiting kann zuverlässig das Erraten von Nachrichten-IDs verhindern.
Für eine noch höhere Schutz der Informationen könnte das Meldeportal dem Hinweisgeber die Möglichkeit geben, zusätzlich zur Nachrichten-ID ein eigenes Passwort zu wählen, das neben der ID für den Zugriff auf die Nachricht erforderlich ist. Dadurch, dass nur der Hinweisgeber sowohl Nachrichten-ID als auch sein eigenes, geheimes Passwort kennt, ist der Schutz der Nachricht noch einmal verbessert.