Java-2-Sicherheitsrichtlinie migrieren

Verwenden Sie diesen Artikel als Anleitung für die Migration der Java™-2-Sicherheitsrichtlinie.

Informationen zu diesem Vorgang

Frühere Releases von WebSphere Application Server

WebSphere Application Server verwendet den Java-2-Sicherheitsmanager in der Serverlaufzeitumgebung, um zu verhindern, dass Unternehmensanwendungen die Methoden "System.exit" und "System.setSecurityManager" aufrufen. Werden diese beiden Java-APIs von Unternehmensanwendungen aufgerufen, hat dies unerwünschte Folgen. Die API "System.exit" bewirkt beispielsweise, dass die Java Virtual Machine (Anwendungsserverprozess) frühzeitig beendet wird, was sich für einen Anwendungsserver nachteilig auswirken kann.

Für eine ordnungsgemäße Unterstützung der Java-2-Sicherheit muss die gesamte Serverlaufzeitumgebung (mit Aufrufen der API "doPrivileged" an den richtigen Positionen) als privileged gekennzeichnet werden. Außerdem muss die Standardberechtigungsgruppen oder die Standardrichtlinie angegeben werden. Anwendungscode ist nicht berechtigt und unterliegt den Berechtigungen, die in den Richtliniendateien definiert sind. Die Instrumentierung mit der API "doPrivileged" ist für die Unterstützung der Java-2-Sicherheit wichtig und erforderlich. Ohne diese API müssen dem Anwendungscode die Berechtigungen erteilt werden, die für die Laufzeitumgebung des Servers erforderlich sind. Diese Situation ist auf das Design und den Algorithmus zurückzuführen, der von der Java-Sicherheit für die Durchsetzung von Berechtigungsprüfungen verwendet wird. Schauen Sie sich den Algorithmus der Java-2-Sicherheit für Berechtigungsprüfungen an.

Die folgenden beiden Berechtigungen werden vom Java-2-Sicherheitsmanager für WebSphere Application Server durchgesetzt (fest codiert):
  • java.lang.RuntimePermission(exitVM)
  • java.lang.RuntimePermission(setSecurityManager)

Dem Anwendungscode wird unabhängig von der geltenden Java-2-Sicherheitsrichtlinie der Zugang zu diesen Berechtigungen verweigert. Der Serverlaufzeitumgebung werden diese Berechtigungen jedoch erteilt. Alle anderen Berechtigungsprüfungen werden nicht erzwungen.

Es werden nur zwei Berechtigungen unterstützt:
  • java.net.SocketPermission
  • java.net.NetPermission

Es ist jedoch nicht die gesamte Laufzeitumgebung des Servers als berechtigt markiert. Sie müssen dem Anwendungscode alle über die beiden hier aufgeführten Berechtigungen hinausgehenden Berechtigungen einräumen, da andernfalls die Ausführung der Unternehmensanwendung in Frage gestellt ist. Diese Java-2-Sicherheitsrichtlinie für Unternehmensanwendungen ist sehr gemäßigt.

Änderungen

Die Java-2-Sicherheit wird in WebSphere Application Server vollständig unterstützt, d. h., es werden alle Berechtigungen umgesetzt. Die Standardrichtlinie der Java-2-Sicherheit für eine Unternehmensanwendung enthält die empfohlenen Berechtigungen gemäß der Spezifikation Java Platform, Enterprise Edition (Java EE) Version 1.4. Schauen Sie sich die Standardrichtlinie der Java-2-Sicherheit in der Datei Profilstammverzeichnis/config/cells/Zellenname/nodes/Knotenname/app.policy an, die Unternehmensanwendungen zugeteilt wird. Diese Richtlinie ist verglichen mit früheren Releases deutlich strenger.

Jede Richtlinie ist deklarativ. Der Sicherheitsmanager des Produkts stützt sich ausschließlich auf die in Richtliniendateien deklarierten Richtlinien. Es gibt eine Ausnahme von dieser Regeln: Unternehmensanwendungen wird der Zugriff auf die in der Datei Profilstammverzeichnis/config/cells/Zellenname/filter.policy deklarierten Berechtigungen verweigert.

Anmerkung: Die Standardrichtlinie der Java-2-Sicherheit für Unternehmensanwendungen ist wesentlich strenger, und alle Berechtigungen werden in WebSphere Application Server Version 9.0 umgesetzt. Die Sicherheitsrichtlinie kann scheitern, weil dem Anwendungscode nicht die erforderlichen Berechtigungen erteilt werden, wenn Systemressourcen, z. B. System-E/A, über das Programm aufgerufen werden können und der Berechtigungsprüfung unterliegen.

Verwenden Sie im Anwendungscode nicht die Berechtigung setSecurityManager, um einen Sicherheitsmanager zu definieren. Wenn eine Anwendung die Berechtigung setSecurityManager verwendet, tritt ein Konflikt mit dem internen Sicherheitsmanager von WebSphere Application Server auf. Wenn Sie für RMI einen Sicherheitsmanager in einer Anwendung definieren müssen, müssen Sie auch die Option Java-2-Sicherheit verwenden, um den Anwendungszugriff auf lokale Ressourcen zu beschränken auf der Seite "Globale Sicherheit" in der Administrationskonsole von WebSphere Application Server aktivieren. Daraufhin registriert WebSphere Application Server einen Sicherheitsmanager. Der Anwendungscode kann mit der API System.getSecurityManager() prüfen, ob dieser Sicherheitsmanager registriert ist.

Systemeigenschaften migrieren

In früheren Releases wurden die folgenden Eigenschaften für Java-2-Sicherheit verwendet:
  • java.security.policy. Der absolute Pfad der Richtliniendatei (Aktion erforderlich). Diese Systemeigenschaft enthält sowohl die Systemberechtigungen (Berechtigungen, die der JVM und der Serverlaufzeitumgebung des Produkts erteilt werden) als auch die Berechtigungen für Unternehmensanwendungen. Migrieren Sie die Java-2-Sicherheitsrichtlinie der Unternehmensanwendung auf Version 9.0. Lesen Sie hierzu die Schritte für die Migration der Java-2-Sicherheitsrichtlinie.
  • enableJava2Security. Wird verwendet, um die Durchsetzung der Java-2-Sicherheit zu aktivieren (keine Aktion erforderlich). erforderlich). Diese Systemeigenschaft ist veraltet. Zum Aktivieren und Inaktivieren der Java-2-Sicherheit wird ein Flag in der Konfigurations-API von WebSphere verwendet. Aktivieren Sie diese Option in der Administrationskonsole.
  • was.home. Wird in das Installationsverzeichnis von WebSphere Application Server aufgelöst (möglicherweise sind zusätzliche Aktionen erforderlich). Diese Systemeigenschaft ist veraltet. Es wurde durch die Eigenschaften "${user.install.root}" und "${was.install.root}" ersetzt. Wenn das Verzeichnis instanzspezifische Daten enthält, wird ${user.install.root} verwendet, andernfalls ${was.install.root}. In der Umgebung von WebSphere Application Server oder WebSphere Application Server Network Deployment sind beide Eigenschaften beliebig austauschbar. Lesen Sie hierzu die Schritte für die Migration der Java-2-Sicherheitsrichtlinie.

Java-2-Sicherheitsrichtlinie migrieren

Es gibt keine einfache Methode für die automatische Migration der Java-Richtliniendatei auf Version 9.0, weil die Richtliniendatei eine Mischung aus Systemberechtigungen und Anwendungsberechtigungen enthält. Kopieren Sie die Java-2-Sicherheitsrichtlinie für Unternehmensanwendungen manuell in eine Datei was.policy oder app.policy. Die Migration der Java-2-Sicherheitsrichtlinie auf eine Datei was.policy wird jedoch empfohlen, weil Symbole oder eine relative Codebasis anstelle einer absoluten Codebasis verwendet werden. Dieser Prozess hat viele Vorteile. Sie können die in der Datei was.policy definierten Berechtigungen ausschließlich der gewünschten Anwendung zuordnen, während die Berechtigungen in der Datei app.policy für alle Unternehmensanwendungen gelten, die auf dem Knoten ausgeführt werden, auf die sich die Datei app.policy bezieht.

Weitere Einzelheiten zur Richtlinienverwaltung finden Sie im Artikel Richtliniendateien für die Java-2-Sicherheit.

Das folgende Beispiel veranschaulicht die Migration einer Java-2-Sicherheitsrichtlinie von einem früheren Release. Der Inhalt umfasst die Java-2-Sicherheitsrichtliniendatei für die Unternehmensanwendung app1.ear und die Systemberechtigungen, d. h. die Berechtigungen, die der Java Virtual Machine (JVM) und der Serverlaufzeitumgebung des Produkts erteilt werden.

[AIX Solaris HP-UX Linux Windows][z/OS]Die Standardposition der Java-2-Sicherheitsrichtliniendatei ist Profilstammverzeichnis/properties/java.policy. Aus Gründen der Übersichtlichkeit wurden die Standardberechtigungen weggelassen.

[IBM i]Die Standardposition der Java-2-Sicherheitsrichtliniendatei ist Profilstammverzeichnis/properties/java.policy. Aus Gründen der Übersichtlichkeit wurden die Standardberechtigungen weggelassen.

// For product Samples
   grant codeBase "file:${app_server_root}/installedApps/app1.ear/-" {
     permission java.security.SecurityPermission "printIdentity";
     permission java.io.FilePermission "${app_server_root}${/}temp${/}somefile.txt", 
       "read";
   };

Aus Gründen der Deutlichkeit werden in diesem Beispiel alle Berechtigungen als Berechtigungen auf Anwendungsebene migriert. Sie können die Gewährung der Berechtigungen jedoch detaillierter gestalten und z. B. Berechtigungen auf Komponentenebene (Webkomponentenebene, EJB-, Connector- oder Dienstprogramm-JAR-Komponentenebene) oder für nur eine bestimmte Komponente einräumen.

Vorgehensweise

  1. Stellen Sie sicher, dass die Java-2-Sicherheit für den Anwendungsserver inaktiviert ist.
  2. Erstellen Sie eine neue Datei was.policy, wenn die Datei nicht vorhanden ist, oder aktualisieren Sie die Datei was.policy für die migrierten Anwendungen im Konfigurationsrepository mit den folgenden Angaben:
    grant codeBase "file:${application}" {
         permission java.security.SecurityPermission "printIdentity";
         permission java.io.FilePermission "
                 ${user.install.root}${/}temp${/}somefile.txt", "read";
       };

    Die dritte und vierte Zeile in diesem Code sind nur zu Darstellungszwecken umgebrochen.

    Die Datei was.policy befindet sich im Verzeichnis Profilstammverzeichnis/config/cells/Zellenname/applications/app.ear/deployments/app/META-INF/.

  3. Ordnen Sie mit einem Assembliertool die Datei was.policy der EAR-Datei (Enterprise Archive) zu.

    Sie können mit dem Assembliertool auch den Inhalt der Datei was.policy überprüfen. Weitere Informationen hierzu finden Sie im Artikel Datei "was.policy" für Java-2-Sicherheit konfigurieren.

  4. Stellen Sie sicher, dass die Unternehmensanwendung zusätzlich zu den migrierten Java-Sicherheitsberechtigungen und den Standardberechtigungen, die in der Datei ${user.install.root}/config/cells/Zellenname/nodes/Knotenname/app.policy deklariert sind, keine weiteren Berechtigungen erfordert. Diese Validierung erfordert eine Codeüberprüfung, eine Überprüfung der Anwendungsdokumentation und Sandbox-Tests der migrierten Unternehmensanwendungen mit aktivierter Java-2-Sicherheit in einer Vorproduktionsumgebung. Informieren Sie sich, welche APIs des Developer Kit mit der Java-2-Sicherheit geschützt werden. Wenn Sie Bibliotheken von Fremdanbietern verwenden, können Sie in der Dokumentation des Anbieters nachlesen, welche APIs durch Java-2-Sicherheit geschützt sind. Vergewissern Sie sich, dass der Anwendung alle erforderlichen Berechtigungen eingeräumt werden, da andernfalls Anwendungsfehler auftreten können, sobald die Java-2-Sicherheit aktiviert wird.
  5. Testen Sie die migrierte Unternehmensanwendung mit aktivierter Java-2-Sicherheit in einer Vorproduktionsumgebung. Aktivieren Sie für den Test den Trace für den Java-2-Sicherheitsmanager von WebSphere Application Server in einer Testumgebung vor der Produktion mit der folgenden Tracezeichenfolge: com.ibm.ws.security.core.SecurityManager=all=enabled. Diese Tracefunktion kann hilfreich beim Debugging der Ausnahme AccessControlException sein, die erstellt wird, wenn einer Anwendung nicht die erforderliche Berechtigung erteilt wird oder wenn Systemcode nicht wie erforderlich als berechtigt markiert ist. Der Trace gibt den Stack-Trace und die Berechtigungen aus, die den Klassen im Aufruf-Stack erteilt wurden, wenn die Ausnahme erstellt wird.

    Nähere Informationen finden Sie im Artikel Zugriffssteuerungsausnahme für Java-2-Sicherheit.

    Anmerkung: Da die Java-2-Sicherheitsrichtlinie im Vergleich mit den früheren Releases wesentlich strenger ist, muss der Administrator oder Implementierer seine Unternehmensanwendungen prüfen, um festzustellen, ob zusätzliche Berechtigungen erforderlich sind, bevor er die Java-2-Sicherheit aktiviert. Wenn den Unternehmensanwendungen nicht die erforderlichen Berechtigungen eingeräumt wurden, können sie nicht ordnungsgemäß ausgeführt werden.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



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