Ü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:

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.

Im Folgenden werden die Sicherheit von WebSphere Application Server, die Java™-Sicherheit und die Plattformsicherheit, die in der vorherigen Abbildung dargestellt sind, beschrieben.
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
[AIX Solaris HP-UX Linux Windows][IBM i]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.

[z/OS]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.
Installation von WebSphere Application Server Network Deployment
Wichtig: Auf allen Knoten befindet sich eine Instanz des Node Agent.

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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[AIX Solaris HP-UX Linux Windows][IBM i]Die folgende Abbildung zeigt eine typische mehrschichte Geschäfts-IT-Umgebung. Auf jedem Computerknoten befindet sich eine Instanz des Node Agent. Jeder Produktanwendungsserver setzt sich aus einem Web-Container, einem EJB-Container und dem Subsystem für die Verwaltung zusammen.

[z/OS]Die folgende Abbildung zeigt eine typische mehrschichte Geschäfts-IT-Umgebung. Auf jedem Computerknoten befindet sich eine Instanz des Node Agent. Jeder Produktanwendungsserver setzt sich aus einem Web-Container, einem EJB-Container und dem Subsystem für die Verwaltung zusammen.

Verwaltungssicherheit

[AIX Solaris HP-UX Linux Windows][IBM i]WebSphere Application Server interagieren über die Sicherheitsprotokolle CSIV2 und SAS (Security Authentication Services) sowie über die Protokolle HTTP und HTTPS.
Wichtig: SAS wird nur zwischen Servern der Version 6.0.x und Servern früherer Versionen unterstützt, die in eine Zelle der Version 6.1 eingebunden sind.
[z/OS]WebSphere Application Server interagieren über die Sicherheitsprotokolle CSIV2 und z/OS Secure Authentication Services (z/SAS) sowie über die Protokolle HTTP und HTTPS.
Wichtig: z/SAS wird nur zwischen Servern der Version 6.0.x und früheren Versionen unterstützt, die in eine Zelle der Version 6.1 eingebunden wurden.

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.

[z/OS]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[z/OS]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

WebSphere Application Server weitet die auf Sicherheitsrollen basierte Zugriffssteuerung auf Verwaltungsressourcen aus, sodass auch das Subsystem für JMX-Systemverwaltung, die Benutzerregistrys und der JNDI-Namespace mit einbezogen sind. Das WebSphere-Verwaltungssubsystem definiert vier Sicherheitsrollen für die Verwaltung:
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.
WebSphere Application Server definiert zwei zusätzliche Rollen, die nur verfügbar sind, wenn Sie mit wsadmin-Scripting arbeiten.
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.

Tabelle 1. Java EE-Sicherheitsberechtigungen für Webkomponenten. Die definierten Java EE-Sicherheitsberechtigungen für Webkomponenten sind in der folgenden Tabelle aufgeführt.
Sicherheitsberechtigung Ziel Aktion
java.lang.RuntimePermission loadLibrary  
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * Verbinden
java.io.FilePermission * Lesen, Schreiben
java.util.PropertyPermission * read
Tabelle 2. Definierte Java EE-Sicherheitsberechtigungen für EJB-Komponenten. Die definierten Java EE-Sicherheitsberechtigungen für EJB-Komponenten sind in der folgenden Tabelle aufgeführt.
Sicherheitsberechtigung Ziel Aktion
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * Verbinden
java.util.PropertyPermission * read
Die Standardrichtlinien der Java-2-Sicherheit von WebSphere Application Server basiert auf der Spezifikation Java EE Version 1.4. Die Spezifikation gewährt Webkomponenten Lese- und Schreibzugriff auf alle Dateien im Dateisystem. Diese Zugriffsberechtigung könnte zu weitreichend sein. Die Standardrichtlinie von WebSphere Application Server gewährt Webkomponenten Lese- und Schreibzugriff auf das Unterverzeichnis und die Unterverzeichnisstruktur, in der das Webmodul installiert ist. Die Java-2-Standardsicherheitsrichtlinien für alle Java Virtual Machines und Prozesse von WebSphere Application Server sind in den folgenden Richtliniendateien enthalten:
[IBM i]/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
[IBM i]Wird als Standardrichtlinie für die Java Virtual Machine (JVM) verwendet.
[AIX Solaris HP-UX Linux Windows][z/OS]${java.home}/jre/lib/security/java.policy
[AIX Solaris HP-UX Linux Windows][z/OS]Diese Datei wird als Standardrichtlinie für die Java Virtual Machine (JVM) verwendet.
[AIX Solaris HP-UX Linux Windows][IBM i]${USER_INSTALL_ROOT}/properties/server.policy
[AIX Solaris HP-UX Linux Windows][IBM i]Diese Datei wird als Standardrichtlinie für alle Produktserverprozesse verwendet.
[z/OS]$WAS_HOME/properties/server.policy
[z/OS]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]
  • 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]
  • $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]
  • 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.

Im Allgemeinen benötigen Anwendungen zur Ausführung und für ihre Portierbarkeit auf verschiedene Anwendungsserver nur die in der Java EE-Spezifikation empfohlenen Berechtigungen. Es kann jedoch bestimmte Anwendungen geben, die weitergehende Berechtigungen benötigen. WebSphere Application Server unterstützt das Packen der Datei was.policy in einer beliebigen Anwendung, um der jeweiligen Anwendung zusätzliche Berechtigungen zu erteilen.
Achtung: Beim Gewähren von Sonderberechtigungen für eine Anwendung sollten Sie sehr vorsichtig sein, da das potenzielle Risiko besteht, die Systemintegrität zu verletzen.

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 Sie in der Administrationskonsole in der Anzeige "Globale Sicherheit" die Optionen Verwaltungssicherheit aktivieren und Java-2-Sicherheit verwenden, um den Anwendungszugriff auf lokale Ressourcen zu beschränken angeben, werden diese Informationen neben anderen sensiblen Konfigurationsdaten in einer Reihe von XML-Konfigurationsdateien gespeichert. Sowohl die rollenbasierte Zugriffssteuerung als auch die auf Berechtigungen basierende Zugriffssteuerung der Java-2-Sicherheit dienen dem Schutz der Integrität von Konfigurationsdaten. Dieses Beispiel für den Schutz von Konfigurationsdaten soll veranschaulichen, wie die Systemintegrität aufrechterhalten werden kann.
Achtung: Die Option Globale Sicherheit aktivieren in den früheren Releases von WebSphere Application Server ist identisch mit der Option Verwaltungssicherheit aktivieren in Version 9.0. Die Option "Java-2-Sicherheit aktivieren" in den früheren Releases ist mit der Option "Java-2-Sicherheit verwenden, um den Anwendungszugriff auf lokale Ressourcen zu beschränken" in Version 9.0 identisch.
  • 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][IBM i]

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.

[z/OS]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.

Ausgehend vom Web Server Plug-in von WebSphere Application Server kann die gegenseitige SSL-Authentifizierung zwischen Plug-in und dem HTTPS-Server von WebSphere Application Server konfiguriert werden. Bei Verwendung eines Zertifikats kann das WebSphere Application Server-Plug-in auf die ausschließliche Kommunikation mit den zwei ausgewählten Instanzen von WebSphere Application Server beschränkt werden. Vergleichen Sie hierzu die folgende Abbildung. Zur Reduzierung des Verwaltungsaufwand und der Kosten können Sie selbst signierte Zertifikate verwenden.
Beispiel: Sie möchten den HTTPS-Server auf den WAS-Servern A und B so einschränken, dass er nur SSL-Verbindungen vom WAS-Plug-in W akzeptiert.
Beispiel: Sie möchten den HTTPS-Server in den WebSphere-Anwendungsservern A und B so einschränken, dass er nur SSL-Verbindungen vom WAS-Plug-in W akzeptiert.
  • [AIX Solaris HP-UX Linux Windows][IBM i]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.
  • [z/OS]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.
Konfigurieren Sie den HTTPS-Server des WebSphere-Anwendungsservers B so, dass er das Zertifikat B verwendet und das Zertifikat W anerkennt.
Tabelle 3. Vertrauensbeziehungen aus dem Beispiel. Das Vertrauensverhältnis aus der vorherigen Abbildung ist in der folgenden Tabelle dargestellt.
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.

Möglicherweise empfiehlt es sich, Instanz A von WebSphere Application Server auf die ausschließliche Kommunikation mit Instanz C von WebSphere Application Server und Instanz B von WebSphere Application Server auf die ausschließliche Kommunikation mit Instanz D von WebSphere Application Server zu beschränken. Alle Instanzen von WebSphere Application Server müssen mit Deployment Manager E von WebSphere Application Server kommunizieren können. Wenn Sie ein selbst signiertes Zertifikat verwenden, können Sie deshalb, wie in der Tabelle gezeigt, die CSIv2- und die SOAP/HTTPS-Schlüssel und entsprechenden Vertrauensbeziehungen konfigurieren.
Tabelle 4. CSIv2- und SOAP/HTTPS-Schlüssel und Vertrauensbeziehungen aus dem Beispiel. Die CSIv2- und SOAP/HTTPS-Schlüssel und die entsprechenden Vertrauensbeziehungen sind in der folgenden Tabelle aufgeführt.
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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_plan
Dateiname:csec_plan.html