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.
- 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.
- 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.
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
- 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.
Die Standardposition der
Java-2-Sicherheitsrichtliniendatei ist
Profilstammverzeichnis/properties/java.policy. Aus Gründen der Übersichtlichkeit wurden die Standardberechtigungen weggelassen.
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.