Sicherheitsaspekte im Umfeld des CURSOR-CRM

Sicherheitsaspekte im Umfeld des CURSOR-CRM
Das CURSOR-CRM ist die Basis aller CRM-Produkte (z. B. EVI Jet, TINA), welche die CURSOR Software
AG entwickelt und vertreibt sowie den Kunden bei der Einführung dieser Systeme umfassend
unterstützt. Dieses Dokument gibt einen Überblick über sicherheitsrelevante Themen im
Zusammenhang mit dem Einsatz des CURSOR-CRM bzw. daraus abgeleiteter, branchenspezifischer
Produkte.
1. Architektur des CURSOR-CRM
Die Architektur des CURSOR-CRM ist wie folgt aufgebaut:
Wie die Grafik verdeutlicht, ist das CURSOR-CRM in einer 3-Ebenen-Architektur aufgebaut
(Präsentations-Schicht, Ebene der Geschäftslogiken, Datenhaltungsschicht). Genau genommen
besteht das System aus einer Client- sowie einer Server-Komponente, die beide in Java implementiert
sind.
Die Serverkomponente ist auf einem Java EE - konformen Applikationsserver installiert, d. h. die
Klassen mit der Geschäftslogik werden auf dem EJB - Container des Applikationsservers „deployed“.
Die Kommunikation mit der Datenbank erfolgt über bekannte Standards wie JDBC und SQL
ausschließlich über diese Server-Komponente, wobei Datenänderungen in den meisten Fällen über
„Container Managed Persistence“ sowie Security Features des eingesetzten Applikationsservers
stattfinden.
Eine hohe Systemverfügbarkeit kann sowohl über Virtualisierungs-Technologien als auch über ClusterUmgebungen gewährleistet werden.
Auf der Client-Seite kommen (in einem Multi-User-Betrieb) zum Einen Rich Clients zum Einsatz, welche
über eine entspr. Proxy-Schicht die Enterprise Java Beans des Servers aufrufen. Die 3-EbenenArchitektur ermöglicht aber auch den parallelen Einsatz eines Web Clients, welcher über eine entspr.
Kommunikationsschicht auf denselben Applikationsserver zugreift. Auch die Kommunikation zwischen
Client und Applikationsserver erfolgt über bekannte Standards wie TCP/IP, HTTP und IIOP (Internet
Inter Orb Protocol).
Für die Erstellung und Ausführung von Auswertungen wird das Open Source Tool JasperReports
eingesetzt. Aufgrund der nativen Java-Schnittstelle ist hier eine bessere Performance als bei vielen
anderen Reporting-Tools erzielbar.
Hauptvorteile dieser Architektur:
•
Trennung von Business-Logik und administrativen Aufgaben wie Transaktionsverwaltung:
Implementierung einer Anwendung beschränkt sich auf die Geschäftslogiken.
•
3-Ebenen-Aufteilung ermöglicht die mehrfache und effiziente Wiederverwendung bestehender
Komponenten. So können Rich Client und Web Client auf dieselbe, einmalig vorliegende BusinessLogik des Applikationsservers zugreifen.
•
Applikationsserver können Dienste für andere SOA-fähige Applikationen bereitstellen und dadurch
heterogene Systeme bzw. -landschaften verbinden
•
Skalierbarkeit für höhere Anwenderzahlen durch „Clustern“ mehrerer Applikationsserver mit
entspr. Lastverteilung („load balancing“)
•
Gerade für Java EE - Applikationen auf Basis einer 3-Ebenen-Architektur wird die Entwicklung frei
verfügbarer Software-Komponenten innerhalb der „Open Source - Gemeinde“ forciert.
2. Sicherheitsrelevante Themen im Umfeld des CURSOR-CRM
Aus der oben beschriebenen Architektur ergeben sich verschiedene sicherheitsrelevante Aspekte, die
im Folgenden zusammenfassend betrachtet werden sollen:
•
Die Geschäftsdaten liegen geschützt auf einem Datenbank-Server und sind im Regelfall nur über
den Applikationsserver zugänglich. Lediglich ein (die Datenbank-Passwörter kennender)
Datenbank-Administrator hätte die Möglichkeit, auch über einen SQL-Editor auf die Daten
zuzugreifen.
•
Dasselbe gilt auch für die in der Anwendung integrierten Anwendungsdokumente (z. B.
Einzelbrief-dokumente), so dass auch hier diese Dokumentdateien nicht über Netzwerkfreigaben
sondern nur im Kontext der Applikation und damit unter Berücksichtigung des
Berechtigungskonzeptes (s. u.) zugänglich sind.
•
Zugriffsmöglichkeiten des Clients auf den zentralen Applikationsserver können (wie oben in der
Grafik dargestellt) über eine Firewall restriktiv konfiguriert werden. Die für den Applikationsserver
hierzu frei zu schaltenden Ports werden im Rahmen der üblichen Installationsaktivitäten
abgestimmt.
•
Die Datenübertragung kann auch in einem internen Netzwerk über SSL-Zertifikate verschlüsselt
erfolgen. SSL-Zertifikate gibt es bspw. nicht nur für Mails oder Makros sondern insbesondere auch
für Applikations- und Webserver, wodurch der im Umfeld der CRM-Applikation stattfindende
Datentransfer verschlüsselt werden könnte.
Sicherheitsaspekte_CURSOR-CRM
2
•
•
•
Auch bei einem Zugriff von Außen (z. B. über Terminal-Server) besteht bspw. über VPN die
Möglichkeit, den Datentransfer auch über das Internet zu „tunneln“ und damit vor nicht
authentifizierten Nutzern zu schützen.
Für das Arbeiten mit der CRM-Applikation ist eine vorherige Authentifizierung am System
erforderlich. Innerhalb der Applikation definierte Passwörter werden nur gemäß konfigurierbarer
Richtlinien (s. u.) akzeptiert sowie darüber hinaus verschlüsselt innerhalb der Datenbank abgelegt.
Das CURSOR-CRM besitzt eine eigene Benutzerverwaltung, mit der Möglichkeit der Vergabe
unterschiedlicher Systemrechte für einzelne Benutzergruppen. Weitere Informationen hierzu sind
dem (weiter unten folgenden) Unterkapitel „Berechtigungskonzept“ zu entnehmen.
2.1
Passwortrichtlinien
Für das Arbeiten mit dem CURSOR-CRM bedarf es einer vorherigen System-Authentifizierung mittels
Benutzername sowie dazugehörigem Passwort. Die Passwörter der einzelnen User-Accounts werden
innerhalb der Datenbank der CRM-Applikation verschlüsselt abgelegt. Die Vergabe von Passwörtern
unterliegt hierbei folgenden Richtlinien, welche vom fachlichen Administrator der CRM-Applikation
einzeln vorgebbar sind:
•
2.2
Sicherstellung folgender Kennwort-Kriterien:
o
Mindest-Zeichenlänge (z. B. >= 8 Zeichen)
o
Verwendung von Groß- und Kleinbuchstaben notwendig
o
In neu eingegebenen Passwörtern ist mindestens eine Zahl enthalten
o
Es ist mindestens ein Sonderzeichen enthalten
•
Kennwortwechselzwang: Ablauf des Kennworts nach X Tagen, mit einstellbarer Warnmeldung
Y Tage vor dem Zeitpunkt des Ablaufs
•
Speicherung einer Kennworthistorie, aufgrund welcher die letzten N Kennwörter nicht wieder
verwendet werden können
•
Sperrung eines Accounts bei Überschreitung einer maximalen Anzahl an Anmeldefehlversuchen (z. B. nach drei gescheiterten Versuchen)
Berechtigungskonzept
Das im CURSOR-CRM umgesetzte Berechtigungskonzept erlaubt es, Rechte sowohl auf Datensatz- als
auch auf Feldebene zu definieren sowie diese Rechte einzelnen Berechtigungsgruppen zuzuordnen.
Man unterscheidet hierbei zwischen Leserecht, Schreibrecht und Managerecht. Mit einem reinen
Leserecht sind Datensätze (oder einzelne Felder) für den Anwender „readonly“. Im Falle eines
Schreibrechtes können diese Daten auch geändert werden, und mit einem Managerecht kann ein
Anwender auch selbst die Rechte im Einzelfall abändern.
Bei der Auslieferung des CURSOR-CRM werden per Default einzelne Entitäten mit der Eigenschaft
„Rechtebehaftet“ versehen, so dass auf einzelnen Datensätzen dieser Entitäten Systemrechte initial
vorgebbar sowie anschl. auch änderbar sind. Abhängig von Kundenanforderungen können aber auch
weitere Entitäten in das Berechtigungskonzept integriert werden, was im Einzelnen über das Projekt
abzustimmen wäre.
Für weitergehende Details zum Berechtigungskonzept wird an dieser Stelle auf die entspr.
Dokumentationen der CURSOR Software AG verwiesen.
Sicherheitsaspekte_CURSOR-CRM
3