Sicurezza Java 2
La sicurezza Java™ 2 fornisce un meccanismo di controllo degli accessi capillare e basato su policy che aumenta l'integrità complessiva del sistema verificando le autorizzazioni prima di consentire l'accesso a determinate risorse di sistema protette. Java 2 Security protegge l'accesso alle risorse di sistema come ad esempio l'I/O di file, i socket e le proprietà. Piattaforma Java2, Enterprise Edition ( J2EE ) le guardie di sicurezza accedono alle risorse web come servlet, JavaServer File Pages (JSP) ed Enterprise JavaBeans metodi (EJB).
Poiché la sicurezza Java 2 è relativamente nuova, molte applicazioni esistenti o addirittura nuove potrebbero non essere preparate per il modello di programmazione del controllo degli accessi a grana molto fine che la sicurezza Java 2 è in grado di implementare. Gli amministratori devono comprendere le possibili conseguenze dell'abilitazione della sicurezza Java 2 se le applicazioni non sono preparate per la sicurezza Java 2. La sicurezza Java 2 impone alcuni nuovi requisiti agli sviluppatori e agli amministratori delle applicazioni.
Sicurezza Java 2 per distributori e amministratori
Sebbene la sicurezza Java 2 sia supportata, è disabilitata per impostazione predefinita. È possibile configurare la sicurezza Java 2 e la sicurezza amministrativa indipendentemente l'una dall'altra. La disabilitazione della sicurezza amministrativa non disabilita automaticamente la sicurezza Java 2. È necessario disabilitarlo esplicitamente.
Se le tue applicazioni o librerie di terze parti non sono pronte, avere la sicurezza Java 2 abilitata causa problemi. È possibile identificare questi problemi come sicurezza Java 2 AccessControlExceptions nel registro di sistema o nei file di traccia. Se non sei sicuro dell'idoneità della sicurezza Java 2 delle tue applicazioni, disabilita inizialmente la sicurezza Java 2 per installare l'applicazione e verificare che funzioni correttamente.
Quando la sicurezza Java 2 è abilitata in WebSphere® Application Server, l'insieme di autorizzazioni di sicurezza Java 2 associate alla classe viene creato quando tale classe viene caricata da uno dei WebSphere caricatori di classi. Qualunque non-WebSphere i classloader non dispongono di questo set di autorizzazioni Java WebSphere Application Server file di policy. Il codice associato a questi classloader che dispone del controllo dell'accesso e sta eseguendo un'azione necessita di una sicurezza Java 2 doPrivileged bloccare attorno a quel codice.
La politica incorporata in questi file di politica non può essere resa più restrittiva perché il prodotto potrebbe non avere la necessaria sicurezza Java 2 doPrivileged API in atto. La politica restrittiva è la politica predefinita. Puoi concedere autorizzazioni aggiuntive, ma non puoi rendere l'impostazione predefinita più restrittiva perché AccessControlExceptions le eccezioni vengono generate dall'interno WebSphere Application Server. Il prodotto non supporta una policy più restrittiva rispetto a quella predefinita definita nei file delle policy menzionati in precedenza.
Parecchi file di policy vengono utilizzati per definire la politica di sicurezza per il processo Java. Questi file delle politiche sono statici (la base del codice è definita nel file delle politiche) e nel formato delle politiche predefinito fornito da IBM® Kit per sviluppatori, edizione della tecnologia Java. Per le risorse delle applicazioni aziendali e le librerie di utilità, WebSphere Application Server fornisce un sostegno politico dinamico. La base di codice viene calcolata dinamicamente in base alle informazioni di distribuzione e le autorizzazioni vengono concesse in base ai file di criteri del modello durante il runtime.
Gli errori di sintassi nei file delle politiche causano un errore nel processo del server delle applicazioni, quindi modificare questi file delle politiche con attenzione.
Se un'applicazione non è preparata per la sicurezza Java 2, se il fornitore dell'applicazione non fornisce un filewas.policy file come parte dell'applicazione o se il fornitore dell'applicazione non comunica le autorizzazioni previste, è probabile che l'applicazione causi eccezioni al controllo dell'accesso di sicurezza Java 2 in fase di runtime. Potrebbe non essere ovvio che un'applicazione non è preparata per la sicurezza Java 2. Numerosi aiuti per il debug in fase di esecuzione aiutano a risolvere i problemi delle applicazioni che potrebbero avere eccezioni di controllo dell'accesso. Per ulteriori dettagli, consultare gli aiuti al debug della sicurezza Java 2. Vedere Gestione di applicazioni che non sono pronte per la sicurezza Java 2 per informazioni e strategie per gestire tali applicazioni.
È importante notare che quando Java Security è abilitato nelle impostazioni di sicurezza amministrativa, il gestore della sicurezza installato attualmente non effettua alcun controllo modifyThread E modifyThreadGroup autorizzazioni per thread non di sistema. Consentire web ed Enterprise JavaBeans (EJB) per creare o modificare un thread può avere un impatto negativo su altri componenti del contenitore e può influire sulla capacità del contenitore di gestire i cicli di vita e le transazioni dei bean enterprise.
Sicurezza Java 2 per gli sviluppatori di applicazioni
Gli sviluppatori di applicazioni devono comprendere le autorizzazioni concesse per impostazione predefinita WebSphere policy e i requisiti di autorizzazione delle API SDK che l'applicazione chiama per sapere se sono necessarie autorizzazioni aggiuntive. Il riferimento Autorizzazioni nel Java 2 SDK nella sezione risorse descrive quali API richiedono quale autorizzazione.
I fornitori di applicazioni possono presupporre che le applicazioni dispongano delle autorizzazioni concesse nella policy predefinita menzionata in precedenza. Applicazioni che accedono a risorse non coperte dall'impostazione predefinita WebSphere sono necessarie per concedere le autorizzazioni di sicurezza Java 2 aggiuntive all'applicazione.
Mentre è possibile concedere all'applicazione autorizzazioni aggiuntive in una delle altre dinamiche WebSphere file policy o in uno dei più tradizionalijava.policy file di policy statici, ilwas.policy file, che è incorporato nel file EAR, garantisce che le autorizzazioni aggiuntive siano limitate all'applicazione esatta che le richiede. L'ambito dell'autorizzazione oltre il codice dell'applicazione che la richiede può consentire al codice che normalmente non dispone dell'autorizzazione per accedere a particolari risorse.
Se è in fase di sviluppo un componente dell'applicazione, come una libreria che potrebbe effettivamente essere inclusa in più di una.ear file, lo sviluppatore della libreria deve documentare le autorizzazioni Java 2 richieste dall'assemblatore dell'applicazione. Non c'èwas.policy file per componenti di tipo libreria. Lo sviluppatore deve comunicare le autorizzazioni richieste tramite la documentazione API (Application Programming Interface) o altra documentazione esterna.
Se l'autorizzazione viene utilizzata solo internamente dalla libreria dei componenti e all'applicazione non viene mai concesso l'accesso alle risorse protette dall'autorizzazione, potrebbe essere necessario contrassegnare il codice come privilegiato. Fare riferimento al AccessControlException argomento per maggiori dettagli. Tuttavia, inserendo erroneamente a doPrivileged la chiamata potrebbe aprire buchi di sicurezza. Comprendere le implicazioni di doPrivileged chiamare per esprimere un giudizio corretto.
La sezione sui file dei criteri dinamici in File delle politiche di sicurezza Java 2 descrive come vengono eseguite le autorizzazioni nel filewas.policy i file vengono concessi in fase di esecuzione.
Sviluppare un'applicazione da utilizzare con la sicurezza Java 2 potrebbe rappresentare una nuova competenza e imporre una consapevolezza della sicurezza non precedentemente richiesta agli sviluppatori di applicazioni. La descrizione del modello di sicurezza Java 2 e delle implicazioni sullo sviluppo dell'applicazione va oltre lo scopo di questa sezione. Il seguente URL può aiutarvi a iniziare: https://docs.oracle.com/javase/1.5.0/docs/guide/security/index.html
Aiuti per il debug
IL WebSphere Application Server SYSOUT e il file com.ibm.websphere.java2secman.norethrow proprietà sono i due aiuti principali per il debug.IL WebSphere Registro di sistema o file di traccia
IL AccessControl L'eccezione registrata nel registro di sistema o nei file di traccia contiene la violazione delle autorizzazioni che causa l'eccezione, lo stack di chiamate dell'eccezione e le autorizzazioni concesse a ciascun frame dello stack. Queste informazioni sono generalmente sufficienti per determinare l'autorizzazione mancante e il codice che richiede l'autorizzazione.IL com.ibm.websphere.java2secman.norethrow proprietà
Quando la sicurezza Java 2 è abilitata in WebSphere Application Server, il componente del gestore della sicurezza crea un file java.security.AccessControl eccezione quando si verifica una violazione di autorizzazione. Questa eccezione, se non gestita, spesso causa un errore in fase di esecuzione. Questa eccezione viene registrata anche nel file SYSOUT.Tuttavia, quando la macchina virtuale Java com.ibm.websphere.java2secman.norethrow la proprietà è impostata e ha un valore di VERO, il responsabile della sicurezza non crea il file AccessControl eccezione. Queste informazioni vengono registrate.
Questa proprietà è destinata a un ambiente sandbox o di debug perché indica al gestore della sicurezza di non creare il file AccessControl eccezione. La sicurezza Java 2 non viene applicata. Non utilizzare questa proprietà in un ambiente di produzione in cui un ambiente di sicurezza Java 2 rilassato indebolisce l'integrità che la sicurezza Java 2 intende produrre.
Questa proprietà è utile in un sandbox o in un ambiente di test in cui l'applicazione può essere testata approfonditamente e dove è possibile controllare il registro di sistema o i file di traccia AccessControl eccezioni. Poiché questa proprietà non crea il file AccessControl eccezione, non propaga lo stack di chiamate e non provoca errori. Senza questa proprietà, devi trovarla e risolverla AccessControl eccezioni una alla volta.
Gestione di applicazioni che non sono pronte per la sicurezza Java 2
Se la maggiore integrità del sistema fornita dalla sicurezza Java 2 è importante, contattare il fornitore dell'applicazione per fare in modo che l'applicazione supporti la sicurezza Java 2 o almeno comunichi le autorizzazioni aggiuntive richieste oltre a quelle predefinite WebSphere Application Server politica che deve essere concessa.Il modo più semplice per gestire tali applicazioni è disabilitare la sicurezza Java 2 in WebSphere Application Server. Lo svantaggio è che questa soluzione si applica all’intero sistema e l’integrità del sistema non è così forte come potrebbe essere. La disabilitazione della sicurezza Java 2 potrebbe non essere accettabile a seconda delle politiche di sicurezza dell'organizzazione o della tolleranza al rischio.
grant codeBase "file:${application}" {
permission java.security.AllPermission;
};IL server.policy file
ILserver.policy il file si trova in app_server_root/properties/ directory.
ILserver.policy il file si trova in profilo_root/properties directory.
Questa politica definisce la politica per il WebSphere Application Server classi. Al momento, tutti i processi server sulla stessa installazione condividono lo stessoserver.policy file. Tuttavia, è possibile configurare questo file in modo che ciascun processo del server possa avere un fileserver.policy file. Definire il file dei criteri come il valore di java.security.policy Proprietà del sistema Java. Per dettagli su come definire le proprietà del sistema Java, fare riferimento alla sezione Definizione del processo del file Gestisci server delle applicazioni.
IL java.policy file
Il file rappresenta le autorizzazioni predefinite concesse a tutte le classi. La politica di questo file si applica a tutti i processi avviati dalla Java virtual machine nel file WebSphere Application Server.
ILjava.policy il file si trova in app_server_root/java/lib/security directory.
ILjava.policy il file si trova in${java.home}/lib/security/ directory dove${java.home} è il percorso del Software Development Kit (SDK) che stai utilizzando. Il file dei criteri viene utilizzato in tutto il sistema operativo. Non modificare iljava.policy file.
Risoluzione dei problemi
- Messaggio di errore CWSCJ0314E
Sintomo:
Error message CWSCJ0314E: L'attuale politica di sicurezza di Java 2 ha segnalato una potenziale violazione dell'autorizzazione di sicurezza di Java 2. Fare riferimento alla Guida alla determinazione dei problemi per ulteriori informazioni.{0} Autorizzazione\:{1} Codice\:{2}{3} Analisi dello stack\:{4} Posizione della base di codice\:{5} L'attuale policy di sicurezza Java 2 ha segnalato una potenziale violazione dell'autorizzazione di sicurezza Java 2. Fare riferimento alla Guida alla determinazione dei problemi per ulteriori informazioni.{0} Autorizzazione\:{1} Codice\:{2}{3} Analisi dello stack\:{4} Posizione della base di codice\:{5}Problema:
Il responsabile della sicurezza Java checkPermission Il metodo ha segnalato un'eccezione di sicurezza sull'autorizzazione dell'oggetto con informazioni di debug. Le informazioni riportate possono essere differenti rispetto alla configurazione del sistema. Questo report viene abilitato configurando una traccia RAS (Reliability Availability Service Ability) in modalità debug o specificando una proprietà Java.
Vedere Abilitazione della traccia per informazioni su come configurare la traccia RAS in modalità debug.
Specificare la seguente proprietà nel pannello Impostazioni JVM dalla console di amministrazione:java.security.debug . Valori validi includono:- accedere
- Stampa tutte le informazioni di debug, tra cui: autorizzazione richiesta, codice, stack e posizione della code base.
- canna
- Stampa informazioni di debug tra cui: autorizzazione richiesta, codice e stack.
- errore
- Stampa informazioni di debug tra cui: autorizzazione e codice richiesti.
Risposta consigliata:
L'eccezione segnalata potrebbe essere critica per il sistema protetto. Attiva la traccia di sicurezza per determinare il potenziale codice che potrebbe aver violato la politica di sicurezza. Dopo aver determinato il codice in violazione, verificare se l'operazione tentata è consentita rispetto alla sicurezza Java 2, esaminando tutti i file delle politiche di sicurezza Java 2 applicabili e il codice dell'applicazione.
Se l'applicazione è in esecuzione con Java Mail, questo messaggio potrebbe essere innocuo. Puoi aggiornare ilwas.policy file per concedere le seguenti autorizzazioni all'applicazione:permission java.io.FilePermission "${user.home}${/}.mailcap", "read"; permission java.io.FilePermission "${user.home}${/}.mime.types", "read"; permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read"; permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";- SecurityException - Accesso negato
Sintomo:
Se la sicurezza Java è abilitata e le autorizzazioni per leggere il file jaxm.properties il file non viene concesso, quando viene creata un'istanza SOAPFactory tramite una chiamata a javax.xml.soap.SOAPFactory.newInstance(), o a MessageFactory l'istanza viene creata tramite una chiamata a MessageFactory.newInstance(), UN SecurityException si verifica un'eccezione e la seguente eccezione viene scritta nel registro di sistema:Permesso: /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm .properties: accesso negato ( java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.proprietà Leggere) Codice: com.ibm.ws.wsfvt.test.binding.addr1.binder.AddressBinder In {file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/ ahp6405Node01Cell/DataBinding.ear/address1.war/WEB-INF/lib /addressbinder1.jar} Traccia di stack: java.security.AccessControlException: accesso negato (java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm .properties leggere) .Problema:
La policy Java 2 Security segnala una potenziale violazione dell'autorizzazione Java 2 Security.
Risposta consigliata:
SOAPFactory ignora l'eccezione e passa al mezzo successivo per determinare quale implementazione caricare. Pertanto è possibile ignorare la voce di registro per questa eccezione di sicurezza.
Poiché questo prodotto utilizza SOAPFactory per supportare altre tecnologie di servizi Web, come WS-Addressing (WS-A), WS-Atomic Transaction (WS-AT) e WS-Notification, è possibile ignorare questo SecurityException in qualsiasi applicazione di servizi Web in cui è abilitata la sicurezza Java.
Messaggi
Messaggio:CWSCJ0313E : I flag dei messaggi di debug del gestore sicurezza Java 2 sono inizializzati\: TrDebug: {0}, Accesso: {1}, Pila: {2}, Fallimento: {3}
Problema: Valori configurati degli indicatori del messaggio di debug validi per il gestore della sicurezza.
Messaggio:CWSCJ0307E : viene rilevata un'eccezione imprevista durante il tentativo di determinare la posizione della codebase. Eccezione: {0}
Problema: Viene rilevata un'eccezione imprevista quando viene determinata la posizione della codebase.