Java-Applikations-Server stellen mittlerweile umfangreiche Infrastrukturdienste bereit, die eine Umsetzung von anspruchsvollen E-Business-Anwendungen erleichtern. Daneben ist auch der hohe Grad der Standardisierung ein besonderes Merkmal der Java-Technologie. Dies betrifft zum Beispiel die Multichannel-Fähigkeit, denn zur Unterstützung verschiedener Vertriebswege lassen sich unterschiedliche Client-Typen nutzen. Die Anbindung von Clients im Internet erfolgt typischerweise über Java Server Pages (JSP) oder Web-Services; Clients im Intranet können etwa als Applets oder Java-Applikationen realisiert werden. Die Komponenten der Enterprise Javabeans (EJB) dienen zur Implementierung des Geschäftsmodells (Business Object Model) und der Geschäftsprozesse (Business Process). Die Anbindung von weiteren Systemen etwa Mainframe-basierender Anwendungen oder ERP-Lösungen kann über die inzwischen standardisierte Java Connector Architecture (JCA) erfolgen.
Bei verteilten Systemen - insbesondere bei E-Business-Anwendungen - spielen allerdings auch die Sicherheitsaspekte eine entscheidende Rolle. Dies ist nicht nur vor dem Hintergrund zu sehen, dass mangelndes Vertrauen in die Sicherheit von Internet-Anwendungen deren breite Akzeptanz bisher verhindert hat. Tritt ein Fehlverhalten der Anwendung während des Betriebs auf (unerlaubter Zugriff auf geschützte Daten mit eventuellem Verstoß gegen datenschutzrechtliche Bestimmungen, Systemausfall durch Denial-of-Service-Attacken etc.) kann ein hoher finanzieller Schaden entstehen.
Beim Anwendungsentwurf muss daher zwangsläufig die Frage gestellt werden, wie sich Geschäftsprozesse im unsicheren Internet sicher anbieten und nutzen lassen. Es muss also auch geklärt werden, wie eine permanente Abstimmung zwischen dem Anwendungs- und dem gewünschten Sicherheitsmodell erfolgen kann. Die Spezifikationen von Java 2 Platform Standard Edition (J2SE) sowie Enterprise Edition (J2EE) legen die derzeit wichtigsten Sicherheitsarchitekturen im Kontext von Java fest. So stellt Version 1.4 von J2SE umfassende Funktionen für Authentifizierung, Autorisierung und Verschlüsselung bereit, während J2EE diese Aspekte im Hinblick auf mehrschichtige Applikationen erweitert.
Seit der Version 1.2 der J2SE (JDK 1.2) wird ein feingranulares Sicherheitsmodell unterstützt. Dies bedeutet, dass jeglicher auszuführende Java-Code mit einer "Security Policy" assoziiert werden kann. Sie definiert eine Menge von Rechten, die dem Code gewährt werden sollen, zum Beispiel der Zugriff auf eine bestimmte Ressource. Eine Überprüfung erfolgt durch die Java-Laufzeitumgebung. Die seit kurzem verfügbare Version 1.4 der J2SE (JDK 1.4) bringt eine neue Qualität in Bezug auf die Vollständigkeit der Sicherheitsarchitektur. Es ist möglich, elaborierte Sicherheitskonzepte ausschließlich mit den vom JDK 1.4 vorgegebenen Mitteln umzusetzen:
-Der Java Authentication and Authorization Service (JAAS) verfeinert das Policy-basierende Sicherheitsmodell dahingehend, dass auf Ebene von authentifizierten Benutzern Rechte vergeben werden können. Ferner wird das Konzept von Login-Modulen eingeführt, durch die Schnittstellen für die Anmeldung standardisiert werden.
-Die Java Cryptography Extension (JCE) erweitert die mit dem JDK 1.2 eingeführte Java Cryptography Architecture (JCA). JCA zusammen mit JCE definieren umfangreiche Frameworks für die Bereiche Verschlüsselung, Schlüsselerzeugung und -verwaltung, Zertifikate sowie digitale Signaturen.
-Die Java Secure Socket Extension (JSSE) stellt Funktionen bereit, mit denen eine sichere Kommunikation im Internet erfolgen kann. Hierzu beinhaltet JSSE insbesondere eine Implementierung der Protokolle SSL (Secure Sockets Layer) und TLS (Transport Layer Security).
Insgesamt lässt sich sagen, dass mit dem JDK 1.4 umfangreiche Sicherheitsfunktionen zur Verfügung stehen. So ist es etwa möglich, mit den Bordmitteln des JDK 1.4 Public-Key-Infrastrukturen (PKI) technisch in einer plattformunabhängigen Weise aufzubauen. Ein weiterer Pluspunkt liegt in der einfachen Erweiterbarkeit. Auch wenn das JDK 1.4 eine Reihe von Basisalgorithmen bereits mit ausliefert, können alternative Implementierungen von Dritten nahtlos in die Sicherheitsarchitektur integriert werden.
Schließlich sollte noch die Konfigurierbarkeit von Berechtigungen hervorgehoben werden. Bestimmte sicherheitsrelevante Entscheidungen (zum Beispiel: "Darf Benutzer Meier auf die Datei secret.txt zugreifen?") müssen nicht in das Anwendungsprogramm codiert werden - die Java-Laufzeitumgebung sorgt für die Einhaltung der Sicherheits-Policy.
In der J2EE-Sicherheitsarchitektur ist es ein wesentliches Ziel, IT-Basisdienste möglichst einfach nutzbar zu machen. Sie sollen konfigurierbar und ihre konkrete Implementierung leicht austauschbar sein. Das gilt insbesondere auch für die Sicherheitsdienste, mit denen Web- und EJB-Komponenten vor unerlaubtem Zugriff geschützt und die Kommunikation zwischen den Komponenten sicher gemacht werden sollen.
Die Authentifizierung von Web-Clients erfolgt entweder mit Benutzername und Passwort oder per Zertifikat. Im ersten Fall kann man wählen, ob das Standard-Login-Fenster des Browsers zum Einsammeln der Daten verwendet werden soll oder ein von der Anwendung in Form einer JSP vorgegebenes Formular. Da Benutzername und Passwort jeweils unverschlüsselt in den Aufruf gestellt werden, sollten diese Verfahren unbedingt mit Transportsicherheit kombiniert werden. Die Authentifizierung mit Zertifikaten hat dieses Problem nicht, erfordert jedoch höheren Verwaltungs- und Konfigurationsaufwand. Die Festlegung auf ein Verfahren geschieht erst zum Zeitpunkt der Installation. Die Verwaltung einer Login-Session, welche gewährleistet, dass jeder Benutzer sich nur einmal beim Server anmelden muss (Single-sign-on), ist Aufgabe des Servers. Er nutzt dazu im allgemeinen Cookies.
Anbinden der BenutzerverzeichnisseZur Authentifizierung von Applikations-Clients verwenden die Applikations-Server zunehmend JAAS-Login-Module. Diese sind entweder für gängige Benutzerverzeichnisse im Lieferumfang enthalten oder müssen selbst implementiert werden. Häufig sind in den Unternehmen bereits umfangreiche Benutzerverzeichnisse in Form von LDAP-Verzeichnissen, Datenbanktabellen oder auf der Ebene des Betriebssystems (NT-Domänen, Unix NIS) vorhanden. Diese können in den gängigen Applikations-Servern für die Authentifizierung herangezogen werden. Die Anbindung ist bisher allerdings nicht standardisiert worden.
Die Autorisierung beim Zugriff auf Ressourcen basiert auf dem Konzept der Rolle. Um auf eine bestimmte Ressource, etwa eine HTML-Seite oder eine Entity Bean, zugreifen zu dürfen, muss ein Benutzer in einer bestimmten Rolle agieren. Ist dies nicht der Fall, verweigert das Laufzeitsystem den Zugriff. Die Rollen, die zum Zugriff berechtigen, werden in einer standardisierten Konfigurationsdatei bei der Installation spezifiziert. Die Zuordnung der Benutzer zu Rollen erfolgt auf proprietäre Art. Schützbare Ressourcen im Web-Container sind HTML-Seiten, Servlets und JSPs. Schützbare EJB-Ressourcen sind die Methoden der Enterprise Beans.
Damit lässt sich bereits vieles recht einfach ausdrücken. Will man jedoch bei der Entscheidung über den Zugriff auf eine Methode deren Parameter einbeziehen ("Ein Kassierer darf maximal 10000 Euro überweisen") oder den Zustand der Bean-Instanz ("Ein Kunde darf nur den Kontostand seines eigenen Kontos sehen"), muss man die entsprechenden Tests in den Programmcode einfügen. J2EE standardisiert dazu eine Schnittstelle, die Zugriffe auf die Identität des Aufrufers und seine Zugehörigkeit zu Rollen erlaubt. Diese Tests sind dann allerdings bei der Installation nicht konfigurierbar.
Neben Vertraulichkeit auch Integrität prüfenNeben Authentifizierung und Autorisierung spielt die Sicherung der Daten beim Transport eine wesentliche Rolle. J2EE verwendet hier den Standard SSL, um die Kommunikation zwischen Client und Server zu verschlüsseln. Per Konfiguration lässt sich wählen, ob nur Vertraulichkeit oder auch Integrität der Daten sichergestellt werden sollen. Für zukünftige Fassungen des J2EE-Standards sind Verbesserungen in den Bereichen Instanz-basierende Zugriffskontrolle, Auditing, Management und dynamische Benutzerregistrierung geplant.
Diese Betrachtungen zeigen, dass Authentisierung, Autorisierung und Transportsicherheit bis zu einem gewissen Umfang konfiguriert werden können. Die Web- beziehungsweise EJB-Container sorgen zur Laufzeit dafür, dass die konfigurierten Restriktionen auch tatsächlich eingehalten werden. Dies führt zu einem recht einfachen Programmiermodell und zu hoher Flexibilität. In der Praxis wird man jedoch häufig zusätzliche Aspekte von Hand programmieren müssen. Der J2EE- Standard definiert dazu die nötigen Schnittstellen. J2EE-konforme Applikations-Server bieten diese Standard-Features an, wobei man berücksichtigen muss, dass nur wenige Produkte die aktuelle Version 1.3 erfüllen (http://java.sun.com/j2ee/compatibility.html). Benötigt man darüber hinausgehende Features, muss man auf spezielle Sicherheitswerkzeuge von Anbietern ausweichen, die mit den Herstellern von Applikations-Servern kooperieren.
Einige Bereiche lassen noch zu wünschen übrig. Die in der Spezifikation EJB 2.0 neu hinzugekommenen Message Driven Beans etwa sind noch gar nicht in die Sicherheitsarchitektur integriert. Außerdem fehlt es etwa an Tipps, Beispielen und Tutorials, die eine "richtige" Verwendung des Sicherheitsmodells zeigen. Das J2EE-Referenzbeispiel Petstore von Sun verwendet auf Web-Ebene nur in geringem Maße und auf EJB-Ebene keinerlei Zugriffskontrolle. Das offenbart zwei wesentliche Schwachstellen des J2EE-Sicherheitsmodells. Zum einen ist es sehr schwierig, die Zugriffskontrolle zwischen Web- und EJB-Ebene zu koordinieren. Beschränkt man sich auf die Web-Ebene, liegen die EJB-Komponenten offen für Zugriffe von Applikations- oder Web-Service-Clients. Konzentriert man sich auf die EJB-Ebene, wird es schwierig, benutzerfreundliche Oberflächen zu gestalten. Verwendet man beide Ebenen, ist es problematisch, ein stimmiges Zusammenspiel zu erreichen.
Problematischer Schutz bei Front-ControllerEin noch größerer Schwachpunkt besteht da-rin, dass das derzeitige Web-Sicherheitsmodell für eine große Klasse von Web-Applikationen unzureichend ist. Die meisten Web-Applikationen - unter anderem auch das Petstore-Beispiel - verwenden eine Architektur mit einem Front-Controller in Form eines Servlets, der alle eingehenden Aufrufe aufnimmt und an die passenden JSPs weiterleitet. Mit dem jetzigen J2EE-Sicherheitsmodell kann dann aber nur der Front-Controller per Konfiguration geschützt werden, nicht die dahinter liegenden Komponenten, was eine feingranulare Zugriffskontrolle unmöglich macht. Will man auf diese nicht verzichten, muss man die entsprechenden Tests in die Komponenten programmieren. (ue)
*Die Autoren sind Consultants bei der Interactive Objects Software GmbH (www.io-software.com) in Freiburg und arbeiten derzeit im Rahmen des Vernet-Programms des Bundesministeriums für Wirtschaft und Technologie (BMWi) an IT-Sicherheitstechnologien.
Sicherheitsfunktionen der Java-PlattformAspekte / J2SE / J2EE
Authentisierung / Login-Module im Rahmen von Java Authentication and Authorization Service (JAAS) / konfigurierbar für Web-Clients mit Benutzername/Passwort oder Zertifikat; für Applikations-Clients mittels JAAS; Session-Verwaltung
Autorisierung / im Rahmen von JAAS / rollenbasiert, konfigurierbar für Web- und EJB-Komponenten; zusätzlich Schnittstellen für programmatische Sicherheit; keine Instanz-basierte Zugriffskontrolle
Sichere Kommunikation / im Rahmen von Java Secure Socket Extension (JSSE) mit Secure Sockets Layer (SSL) und Transport Layer Security (TLS)/ konfigurierbar, auf SSL und TLS basierend; Integrität und Vertraulichkeit
Auditing / nein / bisher keine Standardisierung; proprietäre Lösungen
Verschlüsselung von Daten / im Rahmen der Java Connection Architecture (JCA) und Java Cryptography Extension (JCE) / im Rahmen der sicheren Kommunikation, basierend auf SSL und TLS
Administration / Key-Tool zur Erzeugung und Verwaltung von Schlüsselpaaren und Zertifikaten; Policy-Tool zur Manipulation der Policy-Konfigurationsdateien / proprietär in den jeweiligen Applikations-Servern
Schlüsselerzeugung und -verwaltung / siehe Key-Tool / via J2SE
Model-Driven SecurityIm Rahmen der Model-Driven Architecture (MDA) erarbeitet gegenwärtig die Object Management Group (OMG) einen Standard, durch den Architektur und Eigenschaften eines Anwendungssystems unabhängig von einer konkreten Plattform und Ablaufumgebung beschrieben werden können. Die Kernidee des Ansatzes besteht darin, mit Hilfe geeigneter Modellierungssprachen wie etwa der UML ein plattformunabhängiges Modell des geplanten Anwendungssystems zu erstellen. Ein solches Modell wird anschließend automatisiert in ein plattformspezifisches Softwaresystem überführt, das in einer technischen Umgebung, etwa einem J2EE/EJB-Applikations-Server, ausgeführt werden kann.
Die Anwendung des MDA-Ansatzes für den Bereich Sicherheit - Model-Driven Security - besteht darin, dass Sicherheitsaspekte und -anforderungen auf Modellebene explizit beschrieben und mittels Codegenerierung in der Zielplattform umgesetzt werden.
Worin besteht nun der Nutzen von Model-Driven Security? Neben den Vorteilen einer modellbasierenden Vorgehensweise (zum Beispiel größere Plattformunabhängigkeit, Wiederverwendung auf Modellebene und Produktivitätssteigerung) lassen sich für Model-Driven Security insbesondere folgende Argumente anführen:
- Konsistenzüberprüfungen können bereits auf Modellebene vorgenommen werden, so dass eine frühzeitige Identifikation von Sicherheitslöchern möglich ist;
- bessere Abstimmung zwischen dem Anwendungsmodell und dem gewünschten Sicherheitsmodell;
- Sicherheitsinformationen lassen sich in einer für den Menschen adäquaten und verständlichen Weise ausdrücken;
- Codegenerierung für verschiedene Sicherheitsinfrastrukturen.
An der praktischen Umsetzung von Model-Driven Security wird derzeit im Rahmen des Vernet-Programms des BMWi gearbeitet (http://www.vernet-info.de und http://www.arcsecure.de).
Abb: Security mit J2SE und J2EE
Mit den Bordmitteln von JDK 1.4 stehen umfangreiche Sicherheitsfunktionen zur Verfügung, so etwa für Authentisierung und Autorisierung sowie Verschlüsselung. Quelle: Interactiv Objects