Interoperable Security-Infrastuktur für J2EE, CORBA und .NET am

Kopfzeile: Security Integration zwischen J2EE, CORBA und .NET
Titel: Be secure !
Teil 1 – Definition und Überblick über die Sicherheitsmechanismen
Interoperable Security-Infrastuktur für J2EE, CORBA und .NET am Beispiel des Borland
Enterprise Server
von Martin Heinzl
Die Sicherheit in Software-Infrastrukturen wie J2EE, CORBA oder .NET wird immer mehr ein kritischer Faktor
für den Erfolg von Software. Allerdings bilden (die normalerweise üblichen) inkompatiblen Insellösungen u.a.
im Bereich Sicherheit keine Lösung. Eine standardbasierte, technologieübergreifende Sicherheitslösung ist
notwendig.
Software-Infrastrukturen bilden heute keine hermetisch abgeschlossenen Welten mehr. Die heterogenen Systeme haben
sich etabliert und die Unternehmen müssen versuchen, diese zu verbinden. Dabei haben die Web Services einen neuen
Trend begründet: Die Systeme werden sehr lose miteinander gekoppelt und die Daten über XML ausgetauscht. Für die
Kommunikation zwischen Unternehmen oder auch Unternehmenszweigen mögen Web Services eine sehr gute Wahl
darstellen, doch für die serverlastige Infrastruktur innerhalb eines Unternehmens bedarf es einer soliden Infrastruktur, die
nicht nur sicher ist, sondern bei der besonders Aspekte wie Verfügbarkeit, Ausfallsicherheit, Lastverteilung, Wartbarkeit
und Betrieb berücksichtigt werden. CORBA hat sich für deratige Umgebungen als Standard etabliert
Kommunikationsmöglichkeit ist allerdings nicht alles. Bei den heutzutage immer vernetzteren Welten spielt die
Sicherheit eine immer größere Rolle. Sicherheit in den einzelnen Systemen ist allerdings bei weitem nicht ausreichend. Eine
einheitliche und technologieübergreifende
Standard
Kurzbeschreibung
Sicherheitsschicht wird immer wichtiger. Sicherheit ist
Common Security Interoperability Spezifikation
CSIv2
Version 2 von der OMG
ein äußerst komplexes Thema, das sehr viele
Sicherheit wie vom EJB/J2EE Standard verlangt
EJB/J2EE
unterschiedliche Bereiche umfasst. Neben den vielen
Java Authentication Authorization Service
JAAS
Spezifikationen (siehe Tabelle 1), die hier ein Rolle
Java Secure Socket Extension –
JSSE,SSL,TLS
spielen (u.a. CSIv2, EJB/J2EE Security, JAAS, JSSE,
Übertragunssicherheit und Verschlüsselung
Java Cryptographic Extension
SSL, TLS, JCE, digitale Zertifikate. ...) kommen noch
JCE
Digitale Zertifikate benutzt für https und TLS/SSL
X509
Firewalls, Firmenrichtlinen aber auch Sourcecode
Übertragung
Zertifikate
Security, Dateisystemschutz und vieles mehr hinzu.
OMG Spezifikation für CORBA Kommunikation
OMG
Firewall
Sicherheit in verteilten Systemen besteht also aus einem
durhc die Firewall mittels eines GIOP Proxies
Proxy
ausgeklügelten Zusammenspiel von vielen
Tabelle 1)
unterschiedlichen Komponenten.
Die unterschiedlichen Bereicher einer Sicherheitsinfrastruktur
Sicherheit in verteilen Systemen besteht aus den vier fundamentalen Bereichen
(siehe Bild-1) Authentifizierung, Authorisierung, Übertragungssicherheit und Code
Sicherheit. Jeder dieser Bereiche besteht aus verschiedenen Schnittstellen und
implementierten Standards. Dazu kommen noch weitere Bereiche wie z.B. Firewalls,
VPN (Virtual Private Networks), Dateisystemsicherheit, ... . Dieser Artikel will
anhand eines Beispiels die Sicherheitsinfrastruktur vorstellen, die der Borland
Enterprise Server anbietet. Dieser Server enthält ab der Version 6 auch das Produkt
Janeva, eine native CORBA Implementierung für .NET um über die :NET Remoting
API auf J2EE und CORBA Server zuzugreifen. Teil 2-4 dieser Artikelserie werden
dann die Bereiche Authentifizierung, Authorisierung und
Übertragungssicherheit/Firewall im Detail vorstellen.
Bild 1)
Ein Beispiel für eine technolgieübergreifende, standardbasierte Sicherheitsinfrastruktur.
Das hier vorgestellte (siehe Bild-2) Beispiel soll EJB/Java-CORBA/C++-CORBA/.NET Server sowie EJB/JavaCORBA/C++-CORBA/.NET Clients enthalten. Abgesehen von der .NET nach .NET Kommunikation (es wäre ebenfalls
möglich aber nicht sinnvoll) läuft sämtliche Kommunikation über IIOP mit CSIv2 Sicherheitserweiterung. Alle Server
rufen sich in diesem Beispiel ebenfalls gegenseitig auf. Es können sämtliche Produkte auf dem Markt verwendet werden,
die wirklich J2EE 1.3 zertifiziert
sind (also auch IIOP und CSIv2
Unterstützung haben), sowie alle
ORBs, die auch CSIv2 unterstützen.
Der Borland Enterprise Server ist
zur Zeit das einzige Produkt, das
IIOP/CSIv2 in allen Welten
unterstützt. Die einzige
Einschränkung besteht noch im
.NET Server, der noch keine
Authentifizierung/Authorisierung
sondern zur Zeit nur TLS/SSL
Bild 2)
Verschlüsselung unterstützt.
Zusätzlich – nicht auf der Grafik gezeigt – könnten die Klienten auch über einen IIOP-Firewallproxy (Gatekeeper) auf die
Server zugreifen, sollte sich ein Firewall zwischen den Klienten und den Servern befinden. Die dargestellte Grafik zeigt
eine von vielen möglichen Konstellationen. Es sind eine Reihe von anderen Klienten (z.B.. Tomcat-Webcontainer) und
Kommunikationswege möglich.
In diesem Bild wurde die gesamte Welt der Webservices nicht mitbetrachtet, da dies den Rahmen dieser Artikelserie
sprengen würden. Dazu kommt noch, das die Standardisierung der Sicherheit von Webservices noch nicht abgeschlossen
ist. In diesem Umfeld gibt es verschiedene Ansätze. Angefangen von der Verlagerung der Sicherheit auf den HTTPS
Kommunikationsweg bis hin zu verschiedenen Mechanismen, die Nutzdaten der Webservice Kommunikation verschluesselt
zu übertragen. In Bezug auf Webservice Sicherheit kommt bietet der Borland Enterprise Server zur Zeit HTTPS
Kommunikation an (in der Grafik angedeutet), die für den Transport der Webservice Kommunikation genutzt werden kann.
In den folgenden Abschnitten sollen die oben genannten Bereiche einer Sicherheitsinfrastruktur kurz erklärt und deren
Technologien vorgestellt werden.
1) Authentifizierung
Die Frage könnte auch lauten: Wer ist den dass, der auf den Server zugreifen will ?
Authentifizierung bezeichnet die
Überprüfung der vorgegebenen
Identität von Benutzern bei der
Anmeldung beim System. In der
Regel wird diese Authentifizierung
durch Benutzernamen und
Kennwörter oder durch Zertifikate
erreicht. Die Authentifizierung
gewährt dem Benutzer keine
Zugriffsrechte auf Ressourcen. Dies
erfolgt durch die Autorisierung. Bei
fehlender Authentifizierung kann
Bild-3)
nicht festgestellt werden, welche
Person auf die Ressource zugreift.
Für die Authentifizierung sind zwei Spezifikationen besonders wichtig. Zum einen ist dies JAAS (Java Authentication
Authorization Service) und zum anderen CSIv2 (Commen Security Interoperability Version 2). JAAS enthält als einen
zentralen Baustein die Möglichkeit Benutzer und gruppen von Benutzern in sog. Realms zusammenzufassen. Es können
beliebig viele Realms definiert werden. Für jede Realm wird im Server ein Loginmodul instanziiert. Die komplette JAAS
Konfiguration erfolgt in einer Konfigurationsdatei. Da JAAS
ein Standard ist (und mittlerweise auch Teil der Java
Standard Edition J2SE (früher JDK genannt)) sind die
entsprechenden APIs auch definiert, um beliebige eigene
Loginmodule zu schreiben.
Im diesem Bild (Bild 3) können die Klienten Java/RMI,
Java/CORBA, CORBA oder .NET Klienten sein. Die Server
können J2EE oder CORBA Server sein.
Eine weitere wichtige Konfigurationsmöglichkeit im
Umfeld von Authentifizierung ist die Konfiguration von
Bild 4)
„Trust“ (siehe Bild-4). Klienten werden immer nur am ersten
Server real authentifiziert. Der „Server_Backend“
authentifiziert nur die Server 1-3. Daher ist es notwendig, im „Server_Backend“ zu konfigurieren, welchen Servern (1-3)
dieser Server vertrauen darf, das diese Server die echten Klienten ausreichend authentifiziert haben.
Zum Transport der Sicherheitsinformationen kommt schließlich die Spezifikation CSIv2 in Spiel. Zwei wichtige
bereiche werden hier spezifiziert. Zum ersten wird hier spezifiziert (siehe Bild) wie die unterschiedlichen
Sicherheitsdomänen in den Referenzen auf den Server hinterlegt werden, damit der Klient dies schon aus der IOR auslesen
kann. Zum zweiten wird hier spezifiziert, wie die entsprechenden Sicherheitstoken bei den Aufrufen der
Serverkomponenten (EJBs, CORBA-Objekte, ...) in entsprechenden Servicekontexten des GIOP Protokolls mitübertragen
werden.
Ausserhalb von den hier genannten Spezifikationen besteht hier eine Möglichkeit Sicherheitsinformationen
(normalerweise User/Password/Realm Kombinationen u.a.) nicht als Klartext in irgendwelchen Konfigurationsdateien zu
speichern, sondern in verschlüsselten Dateien, sog. Vault Dateien.
2) Authorisierung
Die Frage könnte auch lauten: Wer darf auf dem Server eigentlich was ?
Authorisierung bezeichnet die Zuweisung von Rechten für authentisierte Benutzer. Sobald ein Benutzer vom System
akzeptiert wurde, kann diesem Benutzer
Zugriffsrechte auf Serverresourcen gegeben bzw.
verweigert werden.
Der größte Teil der Authorisierung
beschäftigt sich mit der Frage, wer darf auf welche
Resourcen zugreifen. Resourcen sind Methoden
auf EJB (Enterprise Java Beans) und Links
(Servlets, JSPs, HTML Seiten, Bilder, Filme, ...)
bei Webanwendungen. Für die J2EE Welt ist dies
in der J2EE und der EJB Spezifikation definiert.
Zugriffsrechte werden hier generell auf Basis von
Bild 5)
logischen Rollen vergeben. Sowohl Zugriffsrechte,
als auch Rollen werden im Deployment Descriptor der entsprechenden Anwendungen definiert.
Im EJB- bzw. Webkontainer werden dann diese logischen Rollen auf eine Liste von physikalischen Usern und
Gruppen umgesetzt. D.h. erst im Kontainer geschieht dann die Zuordnung der logischen Rollen auf die user/Gruppen, gegen
die der Benutzer vorher via JAAS authentifiziert wurde. Der Deployment Descriptor wird ganz bewußt von allen
Infrastrukturabhängigkeiten freigehalten.
Um nicht alle logischen Rollen aller Anwendungen mischen zu müssen, bzw. aufeinander abstimmen zu müssen, gibt
es die Möglichkeit in den Kontainern unterschiedliche Sicherheitsdomänen zu definieren. Jede Sicherheitsdomäne besteht
aus einer Zuordnung von logischen Rollen zu Usern/Gruppen und einigen weiteren Konfiguration wie z.B.
Standardzugriffsrechte, wenn für Resourcen keine expliziten Rechte definiert wurden.
Da CORBA kein vergleichbares Konzept eines Deployment Descriptors kennt, hat z.B. die CORBA Implementierung
VisiBroker eine Erweiterung um die selben Authorisierungskonzepte auf POA bzw. CORBA-Objekt Ebene zu benutzen.
Dies wird durch eine entsprechende „Quality-Of-Protection“ Policy auf POA Ebene und die Implementierung eines
Interfaces erreicht.
3) Transportsicherheit
Die Frage könnte auch lauten: Wer darf die Kommunikation auf dem Transportweg eigentlich verstehen ?
Transportsicherheit bedeutet
Verschlüsselung der Kommunikation
auf dem Transportweg. Der
Transportweg in fast allen Fällen
bedeutet TCP/IP. Sicherheit
Bei der Transportsicherheit
unterscheidet man im wesentlichen
zwischen der Sicherheit einer
normalen TCP/IP Kommunikation
(z.B. über CORBA-IIOP) und einer
Webclient Kommunikation mittels
Bild 6)
HTTP. Beide Kommunikationsformen
können mit ähnlichen Mitteln gesichert
werden. Das zugrundeliegende Protokoll ist in beiden Fällen eine Transportverschlüsselung auf Basis von SSL (Secure
Socket Layer) oder TLS (Transport Layer Security). Beide basieren auf einem asynkronen Public/Private Key Verfahren für
den Erstkontakt. Anschließend kann dann dynamisch auf ein synkrones Verschlüsselungsverfahren gewechselt werden um
eine bessere Performanz zu erzielen.
Zusätzlich zur eigentlichen Verschlüsselung ist es oft wichtig den Sender (Klient) bzw. den Empfänger (Server) zu
identifizieren um zu gewährleisten, das die Nachricht genau denjenigen erreicht, für den sie bestimmt ist. Diese
Authentifizierung geschieht über x509 Zertifikate. Diese Zertifikate werden von bestimmten Institutionen ausgestellt und
digital unterschrieben. In der Java Umgebung bietet das JDK einen Mechanismus an, um diese Zertifikate (sowohl eigene
private Zertifikate, also auch sog. vertrauenswürdige Zertifikate) zu verwalten. Diesen Mechanismus bezeichnet man als
„KeyStores“. Im JDK kommt ein entsprechendes Werkzeug mit um diese KeyStores zu füllen, Zertifikatsanforderungen zu
erstellen und digital signierte Zertifikate in diese KeyStores zu importieren. Eine weitere Möglichkeit mit Zertifikaten zu
arbeiten bietet das Opensource Projekt OpenSSL.
4) Firewalls, Router und VPN Sicherheit
Keine noch so guten Software-Sicherheitsmechanismen sind ausreichend, wenn diese nicht durch entsprechende
Hardwarekomponenten unterstützt werden. Von diesen Hardwarebausteinen gibt es jede Menge. Stellvertretend sollen
einige hier genannt werden.
Die bekanntesten Hardwarekomponenten sind Firewalls oder deren einfachere Geschwister, Router. Diese
Komponenten sind dazu da, bestimmte Netzwerkkommunikationen an deren Ziele durchzulassen, bzw. die Kommunikation
zu unterbinden, wenn diese nicht erwünscht ist. In den meisten Fällen sind diese Maßnahmen für eine CORBA/EJB
Kommunikation nicht ausreichend, bzw. zu grobgranular, da die meisten dieser Hardwarekomponenten die IIOP
Kommunikation nicht verstehen. Die Object Management Group (OMG) hat eine Spezifikation für einen Zusatzproxy für
Firewalls verabschiedet, um Firewalls um das Verständnis von IIOP zu erweitern. Diese Proxies haben eine Reihe von
Eigenschaften, die zwei typische Probleme von IIOP Kommunikation über Firewalls bewältigen sollen. Zum ersten ist das
das Problem der Portbündelung und zum zweiten das Problem der Protokollumsetzung (z.B. HTTP-Tunneling).
Der Borland Enterprise Server enthält eine Implementierung dieses OMG Standards, den sogenannten Gatekeeper.
Dieser unterstützt die folgenden Protokolle: IIOP, HIOP, SSL/IIOP, HTTPS um CORBA/EJB Kommunikation über einen
Firewall zu gewährleisten. Diese Proxies können je nach Bedarf logisch vor oder hinter dem Firewall installiert werden.
Bild 7) Beispiel Deployment
Eine weitere oft verwendete Komponente in der Sicherheitstechnologie ist ein VPN Tunnel („Virtual Private
Network“). Dies ist eine interessante Alternative zur SSL Verschlüsselung, wenn es nur darauf ankommt die Übertragung
auf der Leitung zu sichern und nicht den Sender bzw. Empfänger mittels Zerifikat zu authentisieren.
Diese Liste könnte beliebig erweitert werden, was aber nicht Ziel dieses Artikels ist. Komponenten wie Smartcard
Leser, Finger/Iris Scanner und viele andere Möglichkeiten sind außerhalb dieser Betrachtung.
5) Sicherheit beim Zugriff auf bestimmte Codeelemente
In einem derart komplexen System gibt es noch wesentlich mehr Sicherheitselemente. Eine weitere wichtige Kategorie
ist die Möglichkeit bestimmten Sourcecodeteilen Berechtigungen zu geben bzw. zu verweigern. Im Umfeld vom der Java
Runtime gibt es die Möglichkeit durch Security Manager Codeberechtigungen zu vergeben. Um fertigen Programmen in
einer bestimmten Umgebung
grant codeBase "file:${server.instance.root}/partitions/standard/lib/-" {
Berechtigungen zu geben können
permission java.security.AllPermission;
permission java.io.FilePermission "<<ALL FILES>>", "read, write, delete, execute";
Sourcecode Berechtigungen per
permission java.io.SerializablePermission "enableSubclassImplementation";
permission java.lang.RuntimePermission "checkRealmAccess";
Konfigurationsdatei konfiguriert werden.
permission java.lang.RuntimePermission "checkServletAccess";
permission java.lang.RuntimePermission "checkSetSessionDirectory";
};
Im Microsoft .NET Framework
Beispiel) Java Sourcecode Berechtigungen
wurde vor allem auf Sicherheit sehr viel
Wert gelegt und ähnlich wie im Java Umfeld sind hier vielfältige Sicherheitseinschränkungen und –konfigurationen
möglich. Im Gegensatz zu der alten Win32 Strategie, bei der nur das Benutzerkonto die Rechte festgelegt hat, berücksichtigt
.NET auch – ähnlich wie in Java - die
Quelle des ausführenden
Programmcodes. Diese Code Access
Security vergibt die
Ausführungsrechte nicht an den
Benutzer, sondern nur das konkrete
Programm. Das nachfolgende Bild
zeigt den prinziellen Ablauf der „Code
Access Security“ in einer .NET
Bild 8) Code Access Security im .NET Framework
Anwendung.
Fortsetzung folgt:
Sicherheit ist ein sehr komplexes Thema, bei dem viele unterschiedliche Aspekte und Technologien zusammenspielen
müssen. Die hier genannte Liste könnte noch beliebig fortgesetzt werden. Vor allem im Bereich der verteilten Systeme ist
diese Thematik sehr komplex, da hier noch dazu Sicherheit auf unterschiedlichen Plattformen und über Rechnergrenzen –
potenziell unsichere Netzwerkstrecken – miteinander kombiniert werden muss.
Dieser Artikel sollte einen Eindruck davon geben, wie komplex Sicherheit sein kann und wie viele unterschiedliche
Bestandteile Sicherheit enthalten kann. In den nachfolgenden Artikeln sollen anhand des genannten Beispiels gezeigt
werden, wie Sicherheit in einem J2EE/CORBA System konfiguriert und genutzt werden kann.
Martin Heinzl ist bei Borland als Technologiespezialist im Bereich verteilter System mit dem Schwerpunkt auf J2EE
und CORBA tätig. Als Senior Consultant umfassen seine Tätigkeitsbereiche Training, Architektur- und Produktberatung in
den unterschiedlichsten Projektbereichen (Anforderungen, Softwarearchitektur, Deploymentarchitektur usw. sowie
Projektarbeit.