Übersicht über die Sicherheitsplanung
Wenn Sie auf Informationen im Internet zugreifen, stellen Sie über Web-Server und Produktserver eine Verbindung zu den Unternehmensdaten im Back-End her. Dieser Abschnitt beschäftigt sich mit einigen typischen Konfigurationen und allgemeinen Praktiken in Fragen der Sicherheit.
In diesem Abschnitt wird die Sicherheit untersucht, die die einzelnen Ebenen dieser Architektur bieten. Außerdem erfahren Sie hier, mit welchen allgemeinen Maßnahmen eine angemessene Sicherheit auf beiden Seiten der Verbindung erreicht werden kann. Die folgende Abbildung zeigt die Bausteine für den Schutz von WebSphere Application Server in der Betriebsumgebung:
- WebSphere Application Server-Sicherheit
- WebSphere-Sicherheit
- Die Sicherheit von WebSphere Application Server erzwingt einheitliche Sicherheitsrichtlinien und -services für den Zugriff auf Webressourcen, Enterprise-Beans und JMX-Verwaltungsressourcen. Zur Sicherheit von WebSphere Application Server gehören WebSphere-Sicherheitstechnologien und -features zur Unterstützung einer sicheren Enterprise-Umgebung.
- Java-Sicherheit
- Java EE-Sicherheits-API (Java Platform, Enterprise Edition)
- Der Sicherheits-Collaborator erzwingt die Anwendung Java EE-basierter Sicherheitsrichtlinien und unterstützt die Java EE-Sicherheits-APIs.
- EJB-Sicherheit mit Common Secure Interoperability Protocol Version 2 (CSIv2)
- CSIv2 ist ein dreischichtiges IIOP-basiertes Sicherheitsprotokoll, das von der Object Management Group (OMG) entwickelt wurde. Dieses Protokoll gewährleistet die Sicherheit von Nachrichten sowie gegenseitige Authentifizierung und Delegierung. Die drei Schichten sind eine Basisschicht für Transportsicherheit, eine ergänzende Schicht für Clientauthentifizierung und eine Sicherheitsattributschicht. WebSphere Application Server for z/OS unterstützt CSIv2, Übereinstimmungsstufe 0.
- Java-2-Sicherheit
- Das Sicherheitsmodell von Java 2 ermöglicht eine sehr detaillierte Steuerung des Zugriffs auf Systemressourcen (einschließlich des Dateisystems), Systemeigenschaften, Socket-Verbindungen, Threads, das Laden von Klassen usw. Voraussetzung für den Zugriff auf eine geschützte Ressource ist die explizite Gewährung der entsprechenden Berechtigung durch den Anwendungscode.
- Java Virtual Machine (JVM) 5.0
- Das JVM-Sicherheitsmodell ist eine Sicherheitsebene oberhalb der Betriebssystemebene. Beispielsweise schützt die JVM-Sicherheit den Speicher vor uneingeschränktem Zugriff, löst Ausnahmen aus, wenn Fehler in einem Thread auftreten, und definiert Array-Typen.
- Plattformsicherheit
Betriebssystemsicherheit
Die Sicherheitsinfrastruktur des zugrunde liegenden Betriebssystems stellt bestimmte Sicherheitsservices für WebSphere Application Server bereit. Zu diesen Services gehört die Sicherheitsunterstützung des Dateisystems, die sensible Dateien der Produktinstallation von WebSphere Application Server schützt. Der WebSphere-Systemadministrator kann das Produkt so konfigurieren, dass Authentifizierungsdaten direkt aus der Benutzerregistry des Betriebssystems abgerufen werden.
Betriebssystemsicherheit
Die Sicherheitsinfrastruktur des zugrunde liegenden Betriebssystems stellt bestimmte Sicherheitsservices für WebSphere Application Server bereit. Mit der Betriebssystem-ID des Servants, des Controllers und der Dämontask "Started", wie sie im Profil STARTED festgelegt ist, wird der Zugriff auf Systemressourcen wie Dateien oder Sockets gesteuert. Optional kann die Betriebssystemsicherheit Authentifizierungsservices auf der Basis der Benutzerregistry des lokalen Betriebssystems und/oder Berechtigungsservices auf der Basis der SAF-Berechtigung für die WebSphere-Administrationskonsole und für Anwendungen bereitstellen, die im Anwendungsserver ausgeführt werden.
Der Administrator muss sich nicht nur mit Secure Socket Layer (SSL) und Transport Layer Security (TLS) auskennen, sondern auch mit System Authorization Facility (SAF) und Resource Access Control Facility (RACF) oder einem äquivalenten SAF-basierten Produkt vertraut sein.
Die Identität und Prüfung der Benutzer können mit einem lokalen Betriebssystem als Benutzerregistry, RACF oder einem äquivalenten SAF-Basisprodukt verwaltet werden. Alternativ kann eine LDAP-, angepasste oder eingebundene Benutzerregistry verwendet werden.
WebSphere kann für die Verwendung der SAF-Berechtigung konfiguriert werden, die RACF oder ein äquivalentes SAF-basiertes Produkt verwendet, um Benutzer und Gruppenressourcen zu verwalten und zu schützen. Alternativ kann WebSphere für die Verwendung der WebSphere-Berechtigung oder eines externen JACC-Berechtigungsproviders konfiguriert werden.
Wenn Sie das lokale Betriebssystem als Benutzerregistry und/oder die SAF-Berechtigung verwenden, ist die Sicherheitsprüfung eine integrierte Funktion von RACF und äquivalenter SAF-basierter Produkte.
- Netzsicherheit
- Die Ebenen der Netzsicherheit gewährleisten eine Authentifizierung in der Transportschicht sowie die Integrität und Vertraulichkeit von Nachrichten. Die Kommunikation zwischen verschiednen Anwendungsservern können Sie für die Verwendung von SSL konfigurieren. Eine noch bessere Sicherheit von Nachrichten kann durch die IP-Sicherheit und VPN (Virtual Private Network) erreicht werden.
Jeder Produktanwendungsserver setzt sich aus einem Web-Container, einem EJB-Container und dem Verwaltungssubsystem zusammen.
Der Deployment Manager von WebSphere Application Server enthält nur den Verwaltungscode für WebSphere Application Server und die Administrationskonsole.
Die Administrationskonsole ist eine spezielle Java EE-Webanwendung, die die Schnittstelle für die Ausführung von Verwaltungsfunktionen bildet. Die Konfigurationsdaten von WebSphere Application Server werden in XML-Deskriptordateien gespeichert, die mit den Sicherheitsfunktionen des Betriebssystems geschützt werden müssen. Kennwörter und andere sensible Konfigurationsdaten können über die Administrationskonsole geändert werden. Diese Kennwörter und sensiblen Daten müssen jedoch geschützt werden. Weitere Informationen finden Sie im Artikel Kennwörter in Dateien codieren.
Für die Administrationskonsole gilt die Einschränkung, dass auf die Servlets und JSP-Dateien der Administrationskonsole bei aktivierter Verwaltungssicherheit nur über eine SSL-Verbindung zugegriffen werden kann.
In WebSphere Application Server Version 6.0.x und früheren Versionen wurde der HTTPS-Port der
Administrationskonsole auf die Verwendung der Dateien DummyServerKeyFile.jks und DummyServerTrustFile.jks
mit dem selbst signierten Standardzertifikat eingestellt.
Die Pseudozertifikate und -schlüssel müssen direkt nach der Installation von WebSphere Application Server ersetzt werden.
Diese Schlüssel sind in allen Installationen identisch und daher nicht sicher.
WebSphere Application Server Version 6.1 stellt eine integrierte
Zertifikat- und Schlüsselverwaltung bereit, die eindeutige private Schlüssel und selbst signierte Zertifikate mit integriertem Serverhostnamen
für die Prüfung des Hostnamens generiert.
WebSphere Application Server Version 6.1 unterstützt außerdem die Integration mit externen Zertifizierungsstellen (CA), damit Zertifikate verwendet werden können, die von einer CA ausgestellt werden.
Der Installationsprozess von WebSphere Application Server Version 6.1 bietet eine Option, mit der die Verwaltungssicherheit aktiviert werden kann.
Deshalb ist ein Prozess von WebSphere Application Server direkt nach der Installation sicher. WebSphere Application Server Version 7.0 erweitert die integrierten
Zertifikatsmanagementfunktionen durch Erstellung eines verketteten Zertifikats (persönliches Zertifikat, das von einem Stammzertifikat signiert wurde), wodurch das persönliche Zertifikat aktualisiert werden kann, ohne dass die bestehende Anerkennung beeinträchtigt wird.
Außerdem kann das Zertifikat während der Profilerstellung angepasst werden (Sie können Ihren eigenen DN (Distinguished Name, definierten Name)
importieren oder den standardmäßig erstellten DN ändern) und das Standard-Keystore-Kennwort kann geändert werden.
Die folgende Abbildung zeigt eine typische mehrschichte Geschäfts-IT-Umgebung.
Die folgende Abbildung zeigt eine typische mehrschichte Geschäfts-IT-Umgebung.
Verwaltungssicherheit
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
Sie können diese Protokolle für Secure Sockets Layer (SSL) konfigurieren, wenn Sie WebSphere Application Server Verwaltungssicherheit aktivieren. Das Verwaltungssubsystem von WebSphere Application Server in jedem Server verwendet SOAP, JMX-Connector (Java Management Extensions) und RMI/IIOP-JMX-Connector (Remote Method Invocation over the Internet Inter-ORB Protocol), um Verwaltungsbefehle und Konfigurationsdaten zu übergeben. Bei inaktivierter Verwaltungssicherheit verwendet der SOAP-JMX-Connector das Protokoll HTTP und der RMI/IIOP-Connector das Protokoll TCP/IP. Wenn die Verwaltungssicherheit aktiviert ist, verwendet der SOAP-JMX-Connector immer das Protokoll HTTPS. Der RMI/IIOP-JMX-Connector kann bei aktivierter Verwaltungssicherheit für die Verwendung von SSL oder TCP/IP konfiguriert werden. Es wird empfohlen, die Verwaltungssicherheit und SSL zu aktivieren, um die sensiblen Konfigurationsdaten zu schützen.
Sie können
HTTPS für Anwendungen auch bei inaktivierter Verwaltungssicherheit aktivieren.
Sie können den SSL-Port für einen bestimmten Server konfigurieren, indem Sie den SSL-Port nicht nur wie üblich zu den virtuellen Hosts in der Umgebungskonfiguration, sondern
auch zur HTTP-Portliste im Web-Container des Servers hinzufügen. Anschließend können Sie mit HTTPS und dem richtigen Port eine Verbindung zur
Webanwendung herstellen. Für die interne Kommunikation von
WebSphere Application Server for z/OS
wird SSL nur bei aktivierter Verwaltungssicherheit verwendet.
Wenn die Verwaltungssicherheit aktiviert ist, kann die Anwendungssicherheit auf jedem Anwendungsserver einzeln inaktiviert werden. Dazu muss die Option Verwaltungssicherheit aktivieren auf Serverebene abgewählt werden. Weitere Informationen finden Sie im Artikel Bestimmte Anwendungsserver schützen. Das Inaktivieren der Anwendungsserversicherheit hat keinen Einfluss auf das Verwaltungssubsystem auf dem jeweiligen Anwendungsserver, da dieses von der Sicherheitskonfiguration gesteuert wird. Das Administrationssubsystem und der Anwendungscode auf einem Anwendungsserver benutzen die optionale serverspezifische Konfiguration von Sicherheitsprotokollen gemeinsam.
Sicherheit für Java EE-Ressourcen
Für die Sicherheit von Java EE-Ressourcen sorgen Web-Container und EJB-Container. Jeder Container bietet zwei Arten von Sicherheit: deklarative Sicherheit und programmgesteuerte Sicherheit.
Bei der deklarativen Sicherheit umfasst jede Struktur für Anwendungssicherheit Integrität und Vertraulichkeit von Netznachrichten, Authentifizierungsanforderungen, Sicherheitsrollen und Zugriffssteuerung. Die Zugriffssteuerung wird in anwendungsexterner Form ausgedrückt. Auf der Java EE-Plattform wird die deklarative Sicherheit in erster Linie durch den Implementierungsdeskriptor gewährleistet. WebSphere Application Server erfüllt die Java EE-Sicherheitsrichtlinie. Dazu gehört unter anderem, dass Informationen aus dem Implementierungsdeskriptor abgerufen und von Implementierungsbeauftragten und Administratoren in Form von XML-Deskriptordateien angegeben werden. Zur Laufzeit verwendet der Container die in den XML-Deskriptordateien definierte Sicherheitsrichtlinie, um Vorgaben für Daten und die Zugriffssteuerung durchzusetzen.
Wenn die deklarative Sicherheit allein nicht genügt, um das Sicherheitsmodell einer Anwendung auszudrücken, können Sie die programmgesteuerte Sicherheit für Zugriffsentscheidungen verwenden. Wenn die Verwaltungssicherheit aktiviert ist und die Anwendungsserversicherheit nicht auf Serverebene inaktiviert wird, ist die Java EE-Anwendungssicherheit gewährleistet. Wurde für eine Webressource eine Sicherheitsrichtlinie angegeben, steuert der Web-Container den Zugriff, sobald die Ressource von einem Web-Client angefordert wird. Der Web-Container fragt Authentifizierungsdaten vom Web-Client ab, sofern der Client diese nicht entsprechend dem angegebenen Authentifizierungsverfahren bereitgestellt hat, stellt sicher, dass die Dateneinschränkungen eingehalten werden, und überprüft, ob der authentifizierte Benutzer der erforderlichen Sicherheitsrolle angehört. Der Collaborator für die Websicherheit setzt die rollenbasierte Zugriffssteuerung über eine Zugriffsmanagerimplementierung um. Ein Zugriffsmanager stützt sich beim Gewähren von Berechtigungen auf die Sicherheitsrichtlinie, die aus dem Implementierungsdeskriptor abgerufen wurde. Ein authentifizierter Benutzer-Principal darf auf das angeforderte Servlet oder die angeforderte JSP-Datei zugreifen, wenn er zu einer erforderlichen Rolle gehört. Servlets und JSP-Dateien können die HttpServletRequest-Methoden isUserInRole und getUserPrincipal verwenden.
Wenn die
Verwaltungssicherheit und die Anwendungssicherheit aktiviert sind und die
Anwendungssicherheit auf Anwendungsserverebene nicht inaktiviert ist, setzt der EJB-Container
beim Aufruf von EJB-Methoden eine Zugriffssteuerung durch.
Wenn die Sicherheit auf Zellenebene und die Serversicherheit aktiviert ist,
sorgt der EJB-Container für die Zugriffssteuerung beim Aufruf von EJB-Methoden.
Die Authentifizierung findet unabhängig davon statt, ob für die jeweilige EJB-Methode ein Methodenrecht definiert ist. Der Collaborator für die EJB-Sicherheit setzt die rollenbasierte Zugriffssteuerung über eine Zugriffsmanagerimplementierung um. Ein Zugriffsmanager stützt sich beim Gewähren von Berechtigungen auf die Sicherheitsrichtlinie, die aus dem Implementierungsdeskriptor abgerufen wurde. Ein authentifizierter Benutzer-Principal darf auf die angeforderte EJB-Methode zugreifen, wenn er zu einer der erforderlichen Rollen gehört. EJB-Code darf die EJBContext-Methoden isCallerInRole und getCallerPrincipal verwenden. Verwenden Sie für den Schutz wertvoller Geschäftsdaten vor dem Zugriff unbefugter Personen über das Internet oder Intranet rollenbasierte Java EE-Zugriffssteuerung. Weitere Informationen hierzu finden Sie in den Artikeln Webanwendungen mit einem Assembliertool sichern und Enterprise-Bean-Anwendungen sichern.
Rollenbasierte Sicherheit
- Rolle "Monitor" (Überwachung)
- Ein Monitor kann die Konfigurationsdaten und den Konfigurationsstatus sehen, jedoch keine Änderungen vornehmen.
- Rolle "Operator" (Bedienung)
- Ein Operator kann Änderungen des Laufzeitstatus auslösen (und z. B. einen Anwendungsserver starten oder eine Anwendung stoppen), er kann jedoch keine Konfigurationsänderungen vornehmen.
- Rolle "Configurator" (Konfiguration)
- Der Configurator kann die Konfigurationsdaten ändern, jedoch nicht den Status der Laufzeit.
- Rolle "Administrator" (Verwaltung)
- Ein Bediener und Konfigurationsverantwortlicher, der zusätzlich die sensible Sicherheitskonfiguration und Sicherheitsrichtlinie modifizieren kann. Er kann beispielsweise Server-IDs und Kennwörter festlegen, die Verwaltungssicherheit und Java-2-Sicherheit aktivieren oder inaktivieren und Benutzer und Gruppen der Rolle "Administrator" zuordnen.
- iscadmins
- Die Rolle "iscadmins" hat nur Administratorrechte für die Verwaltung von Benutzern und Gruppen in der Administrationskonsole.
- Deployer
- Ein Deployer kann Konfigurationsaktionen und Laufzeitoperationen in Anwendungen ausführen.
- Adminsecuritymanager
- Ein AdminSecurityManager kann Benutzer zu Verwaltungsrollen zuordnen. Wenn eine differenzierte Verwaltungssicherheit verwendet wird, können Benutzer, die dieser Rolle zugeordnet sind, Berechtigungsgruppen verwalten.
- Auditor
- Auditor können die Konfigurationseinstellungen für das Subsystem für Sicherheitsprüfung anzeigen und ändern.
Ein Benutzer mit der Rolle "Configurator" kann die meisten Verwaltungsaufgaben ausführen. Dazu gehört unter anderem das Installieren neuer Anwendungen und Anwendungsserver. Es gibt bestimmte Konfigurationsaufgaben, die ein Konfigurationsverantwortlicher bei aktivierter Verwaltungssicherheit nicht ausführen darf. Dazu gehören das Ändern der ID und des Kennworts für WebSphere Application Server, das Ändern von LTPA-Kennwort und -Schlüsseln und das Zuordnen von Benutzern zu Sicherheitsrollen für die Verwaltung. Solche sensiblen Konfigurationstasks sind der Rolle "Administrator" vorbehalten, da die Server-ID dieser Rolle zugeordnet wird.
Aktivieren Sie die Verwaltungssicherheit in WebSphere Application Server, um die Integrität des Verwaltungssubsystems zu schützen. Die Sicherheit einzelner Anwendungsserver kann selektiv inaktiviert werden, wenn keine zu schützenden sensiblen Daten vorhanden sind. Weitere Informationen zur Verwaltungssicherheit finden Sie in den Artikeln Zugriff auf Verwaltungsrollen berechtigen und Benutzer und Gruppen Rollen zuordnen.
Java-2-Sicherheitsberechtigungen
WebSphere Application Server erstellt mit dem Java-2-Sicherheitsmodell eine sichere Umgebung für die Ausführung des Anwendungscodes. Die Java-2-Sicherheit sorgt für eine sehr detaillierte und auf Richtlinien gestützte Zugriffssteuerung, mit der Systemressourcen wie Dateien, Systemeigenschaften, das Öffnen von Socket-Verbindungen, das Laden von Bibliotheken usw. geschützt werden. Die Spezifikation Java EE Version 1.4 definiert eine typische Gruppe von Java-2-Sicherheitsberechtigungen, die web und EJB-Komponenten haben sollten.
Sicherheitsberechtigung | Ziel | Aktion |
---|---|---|
java.lang.RuntimePermission | loadLibrary | |
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | Verbinden |
java.io.FilePermission | * | Lesen, Schreiben |
java.util.PropertyPermission | * | read |
Sicherheitsberechtigung | Ziel | Aktion |
---|---|---|
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | Verbinden |
java.util.PropertyPermission | * | read |
/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
Wird als Standardrichtlinie für die Java Virtual Machine (JVM) verwendet.
${java.home}/jre/lib/security/java.policy
Diese Datei wird als Standardrichtlinie für die Java Virtual Machine (JVM) verwendet.
${USER_INSTALL_ROOT}/properties/server.policy
Diese Datei wird als Standardrichtlinie für alle Produktserverprozesse verwendet.
$WAS_HOME/properties/server.policy
Diese Datei wird als Standardrichtlinie für alle Produktserverprozesse verwendet.
Zur Vereinfachung der Richtlinienverwaltung basiert die Richtlinie von WebSphere Application Server auf dem Ressourcentyp und nicht auf der Codebasis (Position). Die folgenden Dateien sind die Standardrichtliniendateien für ein Subsystem von WebSphere Application Server. Diese Richtliniendateien sind eine Erweiterung der Laufzeitumgebung von WebSphere Application Server, werden als SPI (Service Provider Programming Interfaces) bezeichnet und werden von mehreren Java EE-Anwendungen gemeinsam genutzt:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
- Profilstammverzeichnis/config/cells/Zellenname/nodes/Knotenname/spi.policy
Diese Datei wird für integrierte, in der Datei resources.xml definierte Ressourcen verwendet, z. B. für Java Message Service (JMS), JavaMail und JDBC-Treiber.
- Profilstammverzeichnis/config/cells/Zellenname/nodes/Knotenname/library.policy
Diese Datei wird von der gemeinsam genutzten Bibliothek verwendet, die in der Administrationskonsole von WebSphere Application Server definiert ist.
- Profilstammverzeichnis/config/cells/Zellenname/nodes/Knotenname/app.policy
Diese Datei wird als Standardrichtlinie für Java EE-Anwendungen verwendet.
![[z/OS]](../images/ngzos.gif)
- $WAS_HOME/config/cells/Zellenname/nodes/Knotenname/spi.policy
Diese Datei wird für integrierte Ressourcen verwendet, die in der Datei resources.xml definiert sind, z. B. für Java Message Service (JMS), JavaMail-API und JDBC-Treiber.
- $WAS_HOME/config/cells/Zellenname/nodes/Knotenname/library.policy
Diese Datei wird von der gemeinsam genutzten Bibliothek verwendet, die in der Administrationskonsole von WebSphere Application Server definiert ist.
- $WAS_HOME/config/cells/Zellenname/nodes/Knotenname/app.policy
Diese Datei wird als Standardrichtlinie für Java EE-Anwendungen verwendet.
![[IBM i]](../images/iseries.gif)
- Profilstammverzeichnis/config/cells/Zellenname/nodes/Knotenname/spi.policy
Wird für integrierte Ressourcen verwendet, die in der Datei resources.xml definiert sind, wie z. B. Java Message Service (JMS), JavaMail und JDBC-Treiber.
- Profilstammverzeichnis/config/cells/Zellenname/nodes/Knotenname/library.policy
Wird von der gemeinsam genutzten Bibliothek verwendet, die in der Administrationskonsole vor WebSphere Application Server definiert wird.
- Profilstammverzeichnis/config/cells/Zellenname/nodes/Knotenname/app.policy
Diese Datei wird als Standardrichtlinie für Java EE-Anwendungen verwendet.
Durch das Laden der Bibliotheken in WebSphere Application Server haben Anwendungen die Möglichkeit, die Java-Sandbox zu verlassen. WebSphere Application Server verwendet eine Richtliniendatei für das Filtern von Berechtigungen, um Sie zu informieren, wenn eine Anwendungsinstallation wegen fehlender Berechtigungen fehlschlägt. Die Berechtigung "java.lang.RuntimePermission exitVM" sollte beispielsweise keiner Anwendung erteilt werden, damit kein Anwendungscode WebSphere Application Server beenden kann.
Die Filterrichtlinie wird mit der Filtermaske in der Datei Profilstammverzeichnis/config/cells/Zellenname/filter.policy definiert. Darüber hinaus setzt WebSphere Application Server auch eine Filterrichtlinie für die Laufzeit zum Filtern der Laufzeitberechtigung um. Damit wird sichergestellt, dass keinem Anwendungscode eine Berechtigung eingeräumt wird, das die Systemintegrität beeinträchtigen könnte.
Viele für frühere Releases von WebSphere Application Server entwickelte Anwendungen gehen möglicherweise nicht mit der Java-2-Sicherheit konform. Wenn Sie solche Anwendungen schnell auf die neueste Version von WebSphere Application Server migrieren möchten, können Sie diesen Anwendungen mit der Datei was.policy temporär die Berechtigung "java.security.AllPermission" einträumen. Es wird empfohlen, solche Anwendungen zu testen, um sicherzustellen, dass sie in einer Umgebung mit aktivierter Java-2-Sicherheit ausgeführt werden. Dazu muss genau ermittelt werden, welche Berechtigungen erforderlich sind. Anschließend sind jeder Anwendung exakt die erforderlichen Berechtigungen zu gewähren. Das Nichtgewähren der Berechtigung AllPermission kann dazu beitragen, das Risiko einer Beeinträchtigung der Systemintegrität zu verringern. Weitere Informationen zum Migrieren von Anwendungen finden Sie im Artikel Java-2-Sicherheitsrichtlinie migrieren.
Die Laufzeitumgebung von WebSphere Application Server schützt mit der Java-2-Sicherheit sensible Laufzeitfunktionen. Anwendungen, denen die Berechtigung AllPermission eingeräumt wird, haben nicht nur Zugriff auf sensible Systemressourcen, sondern auch auf Laufzeitressourcen von WebSphere Application Server, und können so beiden Ressourcengruppen potenziell Schaden zufügen. Für den Fall, dass eine Anwendung als sicher angesehen werden kann, ermöglicht WebSphere Application Server das Inaktivieren der Java-2-Sicherheit auf Anwendungsserverebene. Sie haben die Möglichkeit, die Java-2-Sicherheit standardmäßig in der Administrationskonsole durchzusetzen und das entsprechende Java-Sicherheits-Flag für einen bestimmten Anwendungsserver zu inaktivieren.
- Wenn die Java-2-Sicherheit angewendet wird, kann kein Anwendungscode auf die Laufzeitklassen von WebSphere Application Server zugreifen, die die Konfigurationsdaten verwalten, solange er nicht über die dazu erforderlichen Laufzeitberechtigungen von WebSphere Application Server verfügt.
- Bei angewendeter Java-2-Sicherheit kann kein Anwendungscode auf die XML-Konfigurationsdateien von WebSphere Application Server zugreifen, solange ihm nicht der dazu erforderliche Schreib-/Lesezugriff gewährt wird.
- Das JMX-Verwaltungssubsystem unterstützt SOAP over HTTP oder HTTPS und eine ferne RMI/IIOP-Schnittstelle und gibt Anwendungsprogrammen damit die Möglichkeit, Konfigurationsdateien und -daten zu extrahieren und zu ändern. Wenn die Verwaltungssicherheit aktiviert ist, kann ein Anwendungsprogramm die Konfiguration von WebSphere Application Server unter der Voraussetzung ändern, dass es gültige Authentifizierungsdaten angeben kann und die Sicherheits-ID zu den erforderlichen Sicherheitsrollen gehört.
- Ist ein Benutzer berechtigt, die Java-2-Sicherheit zu inaktivieren, kann er die Konfiguration von WebSphere Application Server ändern. Dazu gehören auch die Sicherheits-ID von WebSphere Application Server, die Authentifizierungsdaten sowie weitere sensible Daten. Nur Benutzer mit der Sicherheitsrolle "Administrator" sind berechtigt, die Java-2-Sicherheit zu inaktivieren.
- Da die Sicherheits-ID von WebSphere Application Server der Rolle "Administrator" zugeordnet ist, können nur zu dieser Rolle gehörige Benutzer die Verwaltungssicherheit inaktivieren, Server-IDs und Kennwörter ändern, Verwaltungsrollen Benutzer und Benutzergruppen zuordnen usw.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Andere Laufzeitressourcen
Andere WAS-Laufzeitressourcen werden durch ähnliche Mechanismen wie die oben beschriebenen geschützt. Es ist sehr wichtig, dass die Verwaltungssicherheit von WebSphere Application Server aktiviert ist und die Java-2-Sicherheit verwendet wird, um den Anwendungszugriff auf lokale Ressourcen zu beschränken. Die Java EE-Spezifikation definiert mehrere Authentifizierungsmethoden für Webkomponenten: die HTTP-Basisauthentifizierung, die formularbasierte Authentifizierung und die HTTPS-Authentifizierung mit Clientzertifikat. Bei einer Anmeldung mit Clientzertifikat ist es für den Browserclient komfortabel, wenn für die Webressourcen Vorgaben bezüglich integraler oder vertraulicher Daten gelten. Wenn ein Browser mit HTTP auf die Webressource zugreift, wird er vom Web-Container automatisch zum HTTPS-Port umgeleitet. Das Sicherheitsprotokoll CSIV2 bietet ebenfalls Unterstützung für die Authentifizierung mit Clientzertifikat. Die SSL-Clientauthentifizierung kann auch für eine sichere Kommunikation zwischen ausgewählten Servern verwendet werden, die untereinander eine anerkannte sichere Beziehung haben.
Das Sicherheitsprotokoll CSIV2 bietet ebenfalls Unterstützung für die Authentifizierung mit Clientzertifikat. Die SSL-Clientauthentifizierung kann auch für eine sichere Kommunikation zwischen ausgewählten Servern verwendet werden,
die untereinander eine anerkannte sichere Beziehung haben.

In diesem Fall können Sie mit IKEYMAN und den Dienstprogrammen für Zertifikatsverwaltung drei Zertifikate erstellen. Außerdem können Sie Zertifikat W verwenden und die Zertifikat A und B anerkennen. Konfigurieren Sie den HTTPS-Server des WebSphere-Anwendungsservers A so, dass er das Zertifikat A verwendet und das Zertifikat W anerkennt.
Zum Ausführen dieser Task können Sie drei Zertifikate mit Resource Access Control Facility (RACF) generieren: W, A und B. Konfigurieren Sie das Plug-in von WebSphere Application Server für die Verwendung des Zertifikats W und der vertrauenswürdigen Zertifikate A und B. Konfigurieren Sie den HTTPS-Server des WebSphere-Anwendungsservers A so, dass er das Zertifikat A verwendet und das Zertifikat W anerkennt.
Server | Schlüssel | Vertrauensbeziehung |
---|---|---|
WAS-Plug-in | W | A, B |
WebSphere-Anwendungsserver A | A | W |
WebSphere-Anwendungsserver B | B | W |
Der Deployment Manager von WebSphere Application Server ist ein zentraler Verwaltungspunkt. Der Deployment Manager sendet Systemverwaltungsbefehle an jeden einzelnen Anwendungsserver. Wenn die Verwaltungssicherheit aktiviert ist, können Sie WebSphere Application Server so konfigurieren, dass SSL und die gegenseitige Authentifizierung erforderlich sind.
Server | Schlüssel | Vertrauensbeziehung |
---|---|---|
Instanz A von WebSphere Application Server | A | C, E |
Instanz B von WebSphere Application Server | B | D, E |
Instanz C von WebSphere Application Server | C | A, E |
Instanz D von WebSphere Application Server | D | B, E |
Deployment Manager E von WebSphere Application Server | E | A, B, C, D |
Wenn WebSphere Application Server für die Verwendung einer LDAP-Benutzerregistry konfiguriert ist, kann zwischen den einzelnen Anwendungsserversn und dem LDAP-Server SSL mit gegenseitiger Authentifizierung unter Verwendung selbst signierter Zertifikate konfiguriert werden, sodass Kennwörter nicht im Klartext vom WAS-Server zum LDAP-Server übertragen werden.
In diesem Beispiel wurden die Node-Agent-Prozesse nicht diskutiert. Jeder Node Agent muss mit Anwendungsservern desselben Knotens sowie mit dem Deployment Manager kommunizieren. Node Agents müssen aber auch mit LDAP-Servern kommunizieren, wenn sie für die Verwendung einer LDAP-Benutzerregistry konfiguriert sind. Es ist sinnvoll, den Deployment Manager und die Node Agents dasselbe Zertifikat benutzen zu lassen. Angenommen, die Anwendungsserver A und C befinden sich auf einem Computerknoten. In seiner Truststore-Datei muss der Node Agent dieses Knotens die Zertifikate A und C haben.
WebSphere Application Server stellt keine
Registry-Konfiguration und kein Dienstprogramm für die Verwaltung bereit. Außerdem werden keine Richtlinien für das Registry-Kennwort vorgeschrieben.
Sie sollten die von Ihrer Registry empfohlene Kennwortrichtlinie anwenden, die unter anderem die Länge und die Geltungsdauer des Kennworts
festlegt.
Server und Verwaltungssicherheit
- CSIv2-Funktionen (Common Secure Interoperability Version 2)
- Zusicherung der Identität an den nachgeschalteten Server
- Authentifizierungsverfahren auswählen
- Registry oder Repository auswählen
- Java-2-Sicherheit
- Java Authentication and Authorization Service (JAAS)
- Java-EE-Connector-Sicherheit
- Zugriffssteuerungsausnahme für Java-2-Sicherheit
- Angepassten Authentifizierungsprovider mit JASPI implementieren