Donnerstag, 9. März 2006

Gütesiegel für TightGate-Pro, Version 1.2

10-12/2003

Rezertifiziert am 09.03.2006
Befristet bis 08.03.2008
Erstzertifizierung 18.12.2003

Software-System mit VNC-Server, der unter einem gehärteten Betriebssystem eine rollenbasierte Rechtevergabe zur sicheren und datenschutzgerechten Internetanbindung von Verwaltungsarbeitsplätzen ermöglicht.

Kurzgutachten
DIVA-Pro
der m-privacy GmbH

Das Produkt DIVA-Pro wurde in TightGate Pro umbenannt.

Das Gütesiegel für dieses Produkt wurde am 09.03.2006 verlängert.
Das Rezertifizierungsgutachten finden Sie > hier <. 

Zeitpunkt der Prüfung

Juni - Juli 2003

Adresse des Antragstellers

m-privacy GmbH
Schwedenstr. 3
13357 Berlin

Ansprechpartner:

Roman Maczkowsky
Tel.: 030 - 466 064 04
E-Mail: info@m-privacy.de

Adressen des/der Sachverständigen

technisch:
Birger Fritzowski
Kattenbek 33
24248 Mönkeberg

Tel.: 0431 - 2 30 37
Fax: 0431 - 2 30 37
E-Mail: birger@fritzowski.de

rechtlich:
Stephan Hansen-Oest
Speicherlinie 40
24937 Flensburg

Tel.: 0461 - 2 13 53
Fax: 0461 - 2 21 42
E-Mail: sh@datenschutzkontor.de

Kurzbezeichnung des IT-Produktes

DIVA-Pro bietet ein Arbeitsumfeld für eine sichere und datenschutzgerechte Internetanbindung von IT-Arbeitsplätzen.
DIVA-Pro-Systeme bieten diese Sicherheit unabhängig von den verwendeten Programmversionen von Browsern oder E-Mail-Clients.

Detaillierte Bezeichnung des IT-Produktes

Das Grundkonzept der VNC-Software ist die Fernsteuerung oder Nutzung eines entfernten Rechners mittels des "Remote Frame Buffer" (RFB) Protokolls. Dabei erfolgt die Ein- und Ausgabe am steuernden Rechner, dem VNC-Client, die Verarbeitung bzw. Programmausführung dagegen am entfernten VNC-Server.

Über das VNC-Protokoll werden Tastatur und Maus-Eingaben vom Client zum Server übertragen. Die grafische Ausgabe des Servers wird auf gleichem Wege zurück an den Client übertragen und dort angezeigt. Benutzer können den entfernt stehenden Server, völlig transparent, vom Arbeitsplatz aus nutzen.

Die per VNC ausgeführten Programme können nur auf dem VNC-Server, jedoch nicht auf dem lokalen Arbeitsplatzrechner zur Ausführung kommen, daher können sie auch nicht auf lokale Ressourcen wie Speicher (CD-, Festplatten- oder Floppy-) Laufwerke oder andere angeschlossene Geräte zugreifen. Weiterhin kann auch nicht auf andere Ressourcen im Netz zugegriffen werden.

Diese gezielte Unmöglichkeit des Zugriffs auf lokale Ressourcen ist ein Leistungsmerkmal im DIVA-Sicherheitskonzept. Durch diese Konstellation wird der Schutz aller Daten/Ressourcen im zu schützenden Netz per VNC erreicht. Das DIVA-Sicherheitskonzept hat folgende weitere Leistungsmerkmale:

  • keine ausführbaren Inhalte am Arbeitsplatz
  • keine Viren-Problematik
  • kein Zugriff auf Daten im internen Netz
  • zentrale Verwaltung von Usern mit Internetzugang
  • zentrale Mail- und Browser-Wartung
  • zentrale serverbasierte Ablage aller E-Mails
  • speziell "gehärteter" Server durch RSBAC

DIVA-Pro selbst verarbeitet nicht zwangsläufig personenbezogene Daten. Der Haupteinsatzbereich ist der Schutz von Netzen mit personenbezogenen Daten (beim Anschluss an das Internet oder andere offene Netze). Diese Aufgabe löst das Produkt durch die Kombination von VNC und RSBAC in einer vorbildlichen Weise.

Tools, die zur Herstellung des IT-Produktes verwendet wurden

  • Gnu-Compiler GCC 2.95 aus Debian Woody (für Kern- und RSBAC-Tool-Kompilation)
  • RSBAC-Administrationsprogramme (Teil des RSBAC-Systems)
  • Standard Debian Woody-Distribution mit Sicherheits-Updates

Die Basistechnologie RSBAC für die Sicherheitskonfiguration ist ein frei erhältliches Produkt aus dem RSBAC-Projekt. Die Basistechnologie VNC für den Zugang ist ein frei erhältliches Produkt aus dem VNC-Projekt bzw. dem Tight-VNC-Projekt.

 

Zweck und Einsatzbereich

Der Einsatzbereich für das DIVA-Produkt ist vielseitig. Da es sich um eine Lösung handelt, die eine für das interne Netz hochsichere Anbindung an das Internet ermöglicht, ist das Produkt grundsätzlich in vielen Bereichen einsetzbar. Es ist insbesondere auch für den Einsatz bei bzw. durch öffentliche Stellen des Landes Schleswig-Holstein geeignet.

 

Modellierung des Datenflusses

Modellierung des Datenflusses 
Für eine vergrößerte Version bitte auf das Bild klicken.

Der Arbeitsplatz-PC mit dem VNC-Client kann in zwei Varianten auf den DIVA-Pro-Server zugreifen:

Variante 1: über eine unverschlüsselte Verbindung (schwarze Pfeile), hierbei wird die Verbindung über die Netzwerkkomponenten dem Netzwerk-IF (Netzwerk-Interface) des VNC-Servers zur Verfügung gestellt.

Variante 2: VNC über einen SSH-Tunnel (rote Pfeile). In dieser Variante liegt zwischen dem VNC-Viewer und dem TCP/ IP Stack die Sicherheitsschicht (Secure Shell = SSH), die serverseitig ebenfalls über den SSH-Deamon geführt wird.

Serverseitig müssen alle Zugriffsversuche (Lesen, Schreiben, Ausführen, Löschen, Anhängen etc.) durch die Access Enforcement Facility (AEF) und Access Decision Facility (ADF), d.h. in den hinterlegten Rollen zugelassen sein.

In der Variante 1 werden die Daten ungesichert über ein (internes) Netz transportiert. Hier wird davon ausgegangen, dass dieses Netzwerk einer Sicherheitsüberprüfung standhält und nur durch vertrauenswürdige interne Anwender genutzt wird.

Im Installationshandbuch wird darauf hingewiesen, dass sich der DIVA-Pro-Server in der Regel physikalisch im eigenen Hause befindet und daher für diese Verbindungen von den Clients zum DIVA-Pro-Server von einer vertrauenswürdigen und kontrollierten Umgebung ausgegangen und auf eine Verschlüsselung der übertragenen Daten verzichtet wird.

Sollte in Ausnahmefällen das Vertrauen nicht gegeben sein (z.B. Kontrolle durch Revision/DSB bei gleichzeitigem Misstrauen gegenüber der Netzwerkadministration), so kann die Verbindung optional über einen verschlüsselten SSH-Tunnel (siehe Variante 2) hergestellt werden.

Ist das Vertrauen in die Sicherheit des lokalen Netzes generell nicht gegeben, so empfiehlt es sich, den gesamten Netzverkehr (z.B. mit Hilfe von Crypto-Netzwerkkarten) zu verschlüsseln, diese sind jedoch nicht Gegenstand der Zertifizierung.

Die Zugriffskontrolle läuft in mehreren Schritten ab. Das Subjekt (der Prozess) ruft eine Systemfunktion auf, um auf ein Objekt zuzugreifen. Die Erweiterung dieser Funktion, die AEF, holt sich Informationen aus den Systemwerten, etwa die Prozess-ID sowie den Typ und die Identifikation des Zielobjekts. Anschließend ruft sie die Entscheidungskomponente ADF auf und übergibt ihr die gesammelten Systeminformationen sowie die Art des Zugriffs.

Die Anfrage ist zunächst an die zentrale Entscheidungsfunktion der ADF gerichtet. Diese Funktion fordert von allen aktiven Entscheidungsmodulen eine Einzelentscheidung an. Die Module holen sich die jeweils benötigten Attribute aus den Datenstrukturen und fällen eine Entscheidung der Art: erlaubt, egal oder verboten.

Die Zentralfunktion fasst die einzelnen Urteile zusammen und liefert eine Gesamtentscheidung zurück. Die ADF verhält sich dabei restriktiv. Es genügt, wenn ein einzelnes Modul eine negative Antwort gibt, die ADF verbietet dann den Zugriff. Nur wenn alle Module zustimmen, erlaubt sie die Aktion. Ist die Entscheidung negativ, bricht der Systemaufruf ab und liefert einen Zugriffsfehler an den Prozess zurück. Bei einer positiven Entscheidung verzweigt die AEF zum eigentlichen Systemaufruf, ist er erfolgreich, sendet die AEF an die ADF einen Hinweis.

In der ADF ist die zentrale Benachrichtigungsfunktion zuständig, sie ruft alle entsprechenden Modulfunktionen auf. Diese holen sich die aktuellen Attribute aus den Datenstrukturen, aktualisieren sie und bestätigen den korrekten Ablauf.

Hat der Systemaufruf ein neues Objekt erzeugt, enthält die Nachricht der AEF an die ADF auch den Typ und die ID des neuen Objekts. Die Entscheidungsmodule erzeugen dann die Attribute dieses Objekts. Nach der Bestätigung gibt die Systemfunktion die angeforderten Daten und die Kontrolle an den aufrufenden Prozess zurück.

Version des Anforderungskatalogs, die der Prüfung zugrunde gelegt wurde

1.0a

Zusammenfassung der Prüfungsergebnisse

DIVA-Pro bietet mit dem VNC-Server mit rollenbasierter Rechtevergabe ein Arbeitsumfeld für eine sichere und datenschutzgerechte Internetanbindung von IT-Arbeitsplätzen. DIVA-Pro-Systeme bieten diese Sicherheit unabhängig von den verwendeten Programmversionen von Browsern oder E-Mail-Clients und stellen aus Sicht von Datenschutz und Datensicherheit ein Produkt dar, das gesetzlichen Vorgaben entspricht und dies in meist vorbildlicher Weise.

Durch die Art und Weise der Nutzung von Netzen wird eine Verarbeitung personenbezogener Daten ermöglicht, die vor der unberechtigten Kenntnisnahme Dritter geschützt ist. Das Produkt ist in besonderer Weise für den Einsatz bei öffentlichen Stellen geeignet.

 

Beschreibung, wie das IT-Produkt den Datenschutz fördert

Das Produkt fördert den Datenschutz, da es über den VNC-Server mit rollenbasierter Rechtevergabe das Arbeitsumfeld für eine sichere und datenschutzgerechte Internetanbindung von IT-Arbeitsplätzen schafft. Dabei können personenbezogene Daten mit hohem Schutzbedarf in internen Netzwerken vor der unberechtigten Kenntnisnahme Dritter geschützt werden. Die Daten im internen Netz sind mit DIVA-Pro selbst gegen gezielte Angriffe aus dem Internet dauerhaft auf hohem Niveau geschützt.

Durch die Trennung der Administrationsrechte wird das Outsourcing von definierten technischen Administrationsaufgaben datenschutzkonform, d.h. ohne Zugriff auf Nutzer-Daten ermöglicht.
Der DSB-Zugang unterstützt die Arbeit von Revision und Datenschutzbeauftragten bei internen Kontrollen, welche auf dem DIVA-Pro-Server jederzeit unabhängig und im laufenden Betrieb durchgeführt werden können.

Kurzgutachten zur Rezertifizierung Tight-Gate – Pro 1.2

Zeitpunkt der Prüfung

08. Februar 2006 bis zum 15. Februar 2006

 

Adresse des Antragstellers

m-privacy GmbH
Am Köllnischen Park 1
10179 Berlin

 

Adresse der Sachverständigen

Rechtsanwalt Stephan Hansen-Oest
Speicherlinie 40
24937 Flensburg
sh@datenschutzkontor.de

Dipl. Inf. (FH) Andreas Bethke
An de Au 6
25548 Mühlenbarbek
ab@datenschutzkontor.de

 

Kurzbezeichnung

Tight-GateTM – Pro 1.2

 

Änderungen und Neuerungen des Produktes

A. Logfile-Auswerung

Für die Logfile-Auswertung gibt es einen neuen Administrationsaccount mit dem Namen "Inspektion", der im Zuge der Revisionssicherheit geschaffen wurde um die Firewall, Systemprotokolle und Benutzeranmeldungen zu prüfen. Die Speicherung der Log-Files wird durch ein im Produkt standardmäßig implementiertes "logrotate" für alle Log-Dateien beschränkt. Die Regelspeicherfrist beträgt eine Woche bei vier Zyklen. Die Logfiles werden demnach vier Wochen gespeichert und bei Erstellung der Logrotation der fünften Woche wird das Logfile der ersten Woche gelöscht.

Für die RSBAC-Logfiles besteht ein kürzerer Zyklus (sieben Tage) für die Logrotation, die hier täglich erfolgt. Jeweils am achten Tag wird das Logfile des ersten Tages überschrieben usw.

Berichte über die Firewall, den Aufbau des Benutzerprotokolls und die einzelnen Systemprotokolle sind entsprechend im Handbuch in Kapitel IX (Seite 44 ff.) aufgeführt. Der Inspektions-Account kann über die Menüpunkte "Benutzer heute/dauer" oder durch Auswahl des auth.log sämtliche (verfügbaren) User-Anmeldungen am System anzeigen lassen. Dabei sieht er den Zeitpunkt der Anmeldung, sowie den Benutzernamen. Eine weiterführende Kontrolle inhaltlicher Art ist nicht möglich.

B. Fernadmin-Zugriff

Wie im technischen Gutachten von 2003 beschrieben bietet das Produkt einen Fernzugang zu Administrationszwecken per SSH. Dieser kann in der aktuellen Version bei Bedarf über SSH- oder HTTPS-Tunnel auf einen "Rendezvous-Server" erfolgen, muss aber in jedem Fall durch die hausinterne Administration freigegeben werden.

C. Schleusen-Option

In der aktuellen Version wurde eine "Schleusen-Option" (zum Dateitransfer auf die Clients) mit umfangreichen Beschränkungs-Einstellungen (User, Transfer-Richtung, Datei-Typ), sowie ein Interface zu einem On-Access-Virenscanner integriert. Dieses Prinzip folgt zwei Grundprinzipien:

  • Es darf keinen Automatismus zur Durchleitung und Weiterverarbeitung auf der jeweils anderen Schleusenseite geben
  • Der Benutzer soll aktiv (bewusst) die Übergabe steuern.

Das gesamte Prinzip ist ausführlich im Handbuch beschrieben.

D. Neue Schnittstellen

Es wurden weitere Schnittstellen zur Benutzer-Authentifikation gegenüber Microsoft ActiveDirectory-, LDAP- und Kerberos-Servern implementiert. Für die Authentisierung stehen drei Möglichkeiten zur Auswahl:

  • RSBAC lokal: Benutzer werden lokal angelegt und gepflegt
  • LDAP: Benutzer werden auf dem TightGateTM-Pro Server angelegt, die Passwort Authentisierung erfolgt aber gegen einen LDAP-Server
  • Kerberos-5: Benutzer werden auf dem TightGateTM-Pro Server angelegt, die Passwort Authentisierung erfolgt aber gegen einen Active Directory- bzw. Kerberos Server (z.B. MS-Windows 2003

E. Doppel-Anmeldung

Für die revisionssichere Auswertung von Log-Dateien wurde eine neue Option zur Zweitauthentifizierung von Administrationsaufgaben integriert, die es ermöglicht einzelne Administrationsschritte einzelnen Benutzern zu zuordnen.

F. Administrations-Menüs

Alle im System installierten Administrations-Accounts haben nun eine deutsche Menüführung. Darüber hinaus gibt es die Accounts "maint" und "revision", die eine klare organisatorische Trennung der Aufgaben ("maint": Benutzer anlegen und löschen / "revision": inhaltliche Kontrolle) unterstützt. Die inhaltliche Kontrolle der Benutzerdaten kann nur durch den Revisions-Account erfolgen. Da Benutzer i.d.R. nur innerhalb des /home-Verzeichnisses Schreibrechte haben, sind regelmäßig nachfolgende Verzeichnisse betroffen:

  • Das /home/user/[Benutzername]-Verzeichnis, unter dem alle geschriebenen Texte, Mails etc. liegen
  • Das /home/transfer/[Benutzername]-Verzeichnis, in dem die Dateien für die Schleusung liegen und
  • Das /home/tmp_dir/-Verzeichnis, in dem Temporär-Dateien abgelegt werden.

Der Revisions-Account ist somit zur Unterstützung von Datenschutzbeauftragten und Revis oren und deren Aufgabenbereiche gedacht, wodurch dieser Account mit einem "Nur-Lesen"-Recht ausgestattet ist. Funktionalitäten und Beschränkungen des Accounts sind im Handbuch unter Kapitel VIII (Seite 40 ff.) beschrieben.

G. Verbessertes Passwortmanagement

Die RSBAC-Benutzer- und Gruppenverwaltung ist komplett im Systemkern realisiert und unterliegt - anders als die klassischen Methoden - einer fein granulierten Zugriffskontrolle durch alle aktiven Sicherheitsmodelle.

Passwortänderungen sind nur in der Rolle "Maint" (Benutzer-Administrator) oder unter Angabe des alten Passwortes durch den Benutzer selbst möglich. Ein direkter Zugriff auf Authentisierungsdaten durch Prozesse findet nicht statt. Die Passwörter werden mit besserem Hashverfahren (SHA1 statt MD5) und größerem Salt (4 Byte statt 2 Byte) im Kernspeicher abgelegt. Die Hashes sind nur durch die Rolle Security für das Backup auslesbar.

H. Integration des RSBAC-Systems in den Linux-Kernel

M-privacy hat das RSBAC-System und PaX in den Linux-Kernel integriert. Die Attribute sind über das PAX-Modul im RSBAC abgelegt. Eine ausführliche Abhandlung über die Integration befindet sich auf der RSBAC-Homepage http://www.rsbac.org

I. Neue Programme der Benutzerschittstelle

Folgende Programmpakete der Benutzerschnittstelle wurden aktualisiert:

  • Browser: Mozilla und Firefox
  • FTP-Client: KBear FTP
  • Office Suite: OpenOffice 2.0.x
  • Acrobat Reader 7
  • Mailprogramme: KMail und Evolution

Alle Programme laufen in den dafür definierten RSBAC-Rollen und sind nach Definition der Rollenrechte gegeneinander abgeschottet. Insbesondere sind Zugriffe auf die lokalen E-Mail-Ablagen ausschließlich mit dem vorgesehenen E-Mail-Programm möglich. 
In rechtlicher Hinsicht hat es zwischenzeitlich keine Änderung der gesetzlichen Anforderungen gegeben, die für die vorliegende Rezertifizierung von Belang wäre.

 

Version des Anforderungskatalogs, die der Prüfung zugrunde gelegt wurde

Anforderungskatalog Version 1.1

 

Zusammenfassung der Prüfungsergebnisse

Bei der Auswertung der Systemprotokolle kann eine Pseudonymisierung der RSBAC-Logs die Zuordenbark eit der Logs zu einzelnen Personen erschweren. Diese kann systemweit durch den "Config"-Administrator voreingestellt werden. Nur der "Revisions"-Account und der "Security"-Account können de-pseudonymisieren. 
Die Empfehlung von m-privacy ist darüber hinaus, dass anstelle der Log-Auswertung über die integrierten Menüs ein gesicherter zentraler Logserver zum Einsatz kommt. Dies ist positiv zu bewerten.

Ebenfalls positiv ist, dass die Fernwartung über einen "Rendezvous-Server" gänzlich ohne direkten Durchgriff des Herstellers in das Anwendernetz auskommt, womit eine noch höhere Sicherheit implementiert wurde. Hierbei kommt eine Verbindung zum Wartungsobjekt nur dann zustande, wenn sowohl der Hersteller-Support (also m-privacy) von außen als auch ein Administrator des Anwenders von innen zur gleichen Zeit aktiv einen Tunnel zum "Rendezvous-Server" aufbauen. Unangemeldete Zugriffe durch den Fernwarter sind bei dieser Lösung nicht mehr möglich, da Verbindungsversuche von der Firewall konsequent geblockt werden.

Weiterhin ist die Schleusenfunktion mit integrierbarem On-Access-Virenscanner zu verzeichnen, durch den bekannte Viren und Würmer vermieden werden können.
Durch das verbesserte Passwortmanagement werden Dictionary-basierte Angriffe auf die Passwörter praktisch unmöglich. Eine fest eingebaute Verzögerung nach jedem Authentisierungsversuch sorgt zudem dafür, dass lokale Brute-Force-Angriffe eine sehr langwierige Angelegenheit werden. Das neue Verfahren ist damit deutlich sicherer als andere bekannte Verfahren unter Linux. Die Vorgaben an die Passwörter bleiben dabei unverändert.

Alles in allem werden die Neuerungen als Verbesserungen gesehen. Dies gilt ins besondere für die Unterstützung eines Datenschutzbeauftragten durch Revisionsfunktionen und Log-File-Auswertungen.

Zusammenfassend wird das Produkt TightGateTM-Pro in der Version 1.2 als vorbildlich bewertet, da es neben den technischen Sicherheitsmaßnahmen auch die Datenschutzorganisation unterstützt. Zudem wird dem Administrator ein informatives und brauchbares Handbuch zur Verfügung gestellt.