Die Sicherheitsprüfung unterstützt die Verfolgung und Archivierung prüfbarer Ereignisse für die Operationen in der
Web-Service-Laufzeitumgebung.
Wenn die Sicherheitsprüfung für Web-Services aktiviert ist, erfasst und protokolliert das Ereignisgeneratordienstprogramm
Signatur-, Veschlüsselungs-, Sicherheits-, Authentifizierungs- und Delegierungsereignisse in Prüfereignisdatensätzen.
Sie können die Prüfereignisdatensätze analysieren, um mögliche Sicherheitsverstöße
oder potenzielle Schwachstellen in der Sicherheitskonfiguration Ihrer Umgebung zu identifizieren.
Das Subsystem für Sicherheitsprüfungen muss für WebSphere Application Server aktiviert werden, bevor der
Ereignisgenerator Prüfdatensätze für die Laufzeitumgebung von Web Services Security erfassen kann.
Die Erfassung prüfbarer Sicherheitsereignisse erfolgt, wenn Sie das Subsystem für Sicherheitsprüfungen aktiviert haben. Weitere Informationen
zum Aktivieren der Sicherheitsprüfung finden Sie im Artikel "Subsystem für Sicherheitsprüfungen aktivieren".
Die Prüfung von Web Services Security wird nur für die JAX-WS-Laufzeitumgebung aktiviert.
Beim Empfang einer SOAP-Nachricht können verschiedene Prüfereignisse eintreten.
Die Prüfdaten werden während verschiedener Laufzeitoperationen von Web Services Security
erfasst, z. B. während der Validierung der digitalen Signatur einer SOAP-Nachricht, der Entschlüsselung
der Nachricht oder der Überprüfung des Sicherheitsheaders.
Die Prüfdaten werden vom Ereignisgenerator gespeichert und verwaltet und für spätere Analyse in Prüfprotokollen
gespeichert.
Einige der prüfbaren Ereignisse für Web-Services sind im Folgenden aufgeführt:
Signatur
Wenn die digitale Signatur in jedem SOAP-Nachrichtenabschnitt validiert wird,
wird ein SECURITY_SIGNING-Ereignis zusammen mit einem Ergebnis (SUCCESS oder ERROR) an den Ereignisgenerator gesendet.
Ursachencodes, VALID_SIGNATURE oder INVALID_SIGNATURE, werden ebenfalls gesendet.
Die Integrität der Nachricht wird ebenfalls mit einem SECURITY_SIGNING-Ereignis geprüft, das das Ergebnis SUCCESS oder DENIED haben kann.
Die Ursachencodes sind INTEGRITY und INTEGRITY_BAD. In der folgenden Tabelle sind die Signaturereignisse zusammengefasst:
Tabelle 1. Prüfereignisse für die Signatur. Sie können die Prüfereignisdatensätze analysieren, um mögliche Sicherheitsverstöße
oder potenzielle Schwachstellen in der Sicherheitskonfiguration Ihrer Umgebung zu identifizieren.Ereignistyp |
Mögliche Ergebnisse |
Ursachencodes |
SECURITY_SIGNING (digitale Signatur) |
SUCCESS
ERROR
|
VALID_SIGNATURE
INVALID_SIGNATURE
|
SECURITY_SIGNING (Integrität) |
SUCCESS
DENIED
|
INTEGRITY
INTEGRITY_BAD
|
Wenn das SECURITY_SIGNING-Ereignis das Ergebnis DENIED (Verweigert) hat und der
Ursachencode INTEGRITY_BAD lautet, bedeutet dies, dass die Signaturvalidierung bei mindestens einem Nachrichtenabschnitt, der
gemäß Sicherheitsrichtlinie signiert sein muss, fehlgeschlagen ist.
Wenn das SECURITY_SIGNING-Ereignis das Ergebnis ERROR (Fehler) hat und der Ursachencode
INVALID_SIGNATURE lautet, bedeutet dies, dass die Validierung der digitalen Signaturen fehlgeschlagen ist.
Dies könnte zu einem Ursachencode INTEGRITY_BAD im Prüfdatensatz führen, abhängig davon, ob die digitale Signatur
gemäß Sicherheitsrichtlinie erforderlich ist.
Verschlüsselung
Die Verschlüsselungsprüfung wird in zwei Phasen durchgeführt:
Zuerst werden die verschlüsselten Abschnitte der SOAP-Nachricht verarbeitet, und anschließend wird die
Vertraulichkeit der Nachricht geprüft.
Für die Prüfung jedes verschlüsselten Abschnitts der Nachricht wird ein
SECURITY_ENCRYPTION-Ereignis gesendet.
Ein Ereignissatz wird nur erstellt, wenn das Ereignis das Ergebnis ERROR hat, d. h., wenn eine Ausnahme eingetreten ist.
Der Ursachencode ist DECRYPTION_ERROR.
Anschließend wird die Vertraulichkeit der Nachricht mit einem weiteren SECURITY_ENCRYPTION-Ereignis geprüft, das die
möglichen Ergebnisse SUCCESS (Erfolg) und DENIED (Verweigert) hat. Die Ursachencodes
für dieses Ereignis sind CONFIDENTIALITY und CONFIDENTIALITY_BAD. In der folgenden Tabelle sind die Verschlüsselungsereignisse
zusammengefasst:
Tabelle 2. Prüfereignisse für die Verschlüsselung. Sie können die Prüfereignisdatensätze analysieren, um mögliche Sicherheitsverstöße
oder potenzielle Schwachstellen in der Sicherheitskonfiguration Ihrer Umgebung zu identifizieren.Ereignistyp |
Mögliche Ergebnisse |
Ursachencodes |
SECURITY_ENCRYPTION (verschlüsselte Nachrichtenabschnitte) |
ERROR |
DECRYPTION_ERROR |
SECURITY_ENCRYPTION (Vertraulichkeit) |
SUCCESS
DENIED
|
CONFIDENTIALITY
CONFIDENTIALITY_BAD
|
Wenn das SECURITY_ENCRYPTION-Ereignis das Ergebnis DENIED (Verweigert) hat und der Ursachencode CONFIDENTIALITY_BAD lautet, bedeutet dies,
dass mindestens ein Nachrichtenabschnitt, der verschlüsselt sein muss, nicht ordnungsgemäß verschlüsselt wurde.
Ein Ursachencode DECRYPTION_ERROR im Prüfsatz kann zu einem Ursachencode CONFIDENTIALITY_BAD führen, abhängig davon, ob eine
Nachrichtenverschlüsselung erforderlich ist.
Zeitmarke
Für jede SOAP-Nachricht wird die Zeitmarke geprüft, wenn ein
SECURITY_RESOURCE_ACCESS-Ereignis an den Ereignisgenerator gesendet wird.
Die möglichen Ergebnisse dieses Ereignisses sind SUCCESS (Erfolg) und DENIED (Verweigert). Die Ursachencodes sind TIMESTAMP und TIMESTAMP_BAD. In der folgenden Tabelle
sind die Zeitmarkenereignisse zusammengefasst:
Tabelle 3. Prüfereignisse für die Zeitmarke. Sie können die Prüfereignisdatensätze analysieren, um mögliche Sicherheitsverstöße
oder potenzielle Schwachstellen in der Sicherheitskonfiguration Ihrer Umgebung zu identifizieren.Ereignistyp |
Mögliches Ergebnis |
Ursachencode |
SECURITY_RESOURCE_ACCESS |
SUCCESS
DENIED
|
TIMESTAMP
TIMESTAMP_BAD
|
Sicherheitsheader
Der Sicherheitsheader wird geprüft, um sicherzustellen, dass
er nicht in der SOAP-Nachricht fehlt.
Es wird ein SECURITY_RESOURCE_ACCESS-Ereignis gesendet, und wenn der Header fehlt, ist das Ergebnis DENIED und der Ursachencode SECURITY_HEADER_MISSING. In der folgenden Tabelle sind die
Sicherheitsheaderereignisse zusammengefasst:
Tabelle 4. Prüfereignisse für den Sicherheitsheader. Sie können die Prüfereignisdatensätze analysieren, um mögliche Sicherheitsverstöße
oder potenzielle Schwachstellen in der Sicherheitskonfiguration Ihrer Umgebung zu identifizieren.Ereignistyp |
Mögliches Ergebnis |
Ursachencode |
SECURITY_RESOURCE_ACCESS |
DENIED |
SECURITY_HEADER_MISSING |
Authentifizierung
Das für die Authentifizierung
einer Nachricht verwendete Sicherheitstoken wird geprüft, um festzustellen, ob die
Authentifizierung erfolgreich war, und Informationen zum Authentifizierungstyp, Providernamen und Providerstatus
werden im Prüfereignissatz gespeichert.
Außerdem wird die Token-ID zusammen mit Informationen aufgezeichnet, die speziell für den Tokentyp gelten, wie z. B.
der Benutzername oder der Keystore.
Sensible Informationen wie das Token selbst oder das Tokenkennwort werden nicht im Prüfereignissatz aufgezeichnet.
Die für jeden Tokentyp aufgezeichneten Informationen sind in der folgenden Tabelle beschrieben:
Tabelle 5. Im Prüfereignissatz aufgezeichnete Tokeninformationen. Sie können die Prüfereignisdatensätze analysieren, um mögliche Sicherheitsverstöße
oder potenzielle Schwachstellen in der Sicherheitskonfiguration Ihrer Umgebung zu identifizieren.Tokentyp |
Aufgezeichnete Informationen |
Benutzernamenstoken |
- Username
- Kennwort (null oder nicht null)
- Token-ID
|
LTPA |
- Principal
- Verfallsdatum
- Token-ID
|
LTPAPropagate |
- Principal
- Verfallsdatum
- Token-ID
|
SecureConversation |
- UUID
- Instanz-UUID
- Token-ID
|
DerivedKey |
|
Kerberos |
- Principal
- SPN
- pSHA1
- Token-ID
|
X509 |
- Zertifikat
- Subject-Objekt
- Aussteller
- Keystore
- Token-ID
- TrustAny
|
PKP Path (Public Key Infrastructure) |
- Zertifikat
- Subject-Objekt
- Aussteller
- Keystore
- Token-ID
- TrustAny
|
PKCS7 (Public Key Cryptography Standards) |
- Zertifikat
- Subject-Objekt
- Aussteller
- Keystore
- Token-ID
- TrustAny
|
SAML-Token |
- Principal
- Name des Ausstellers des SAML-Tokens
- Bestätigungsmethode
|
Die Nachrichtenauthentifizierung wird mit einem SECURITY_AUTHN-Ereignis geprüft.
Die möglichen Ergebnisse des Ereignisses sind SUCCESS (Erfolg), DENIED (Verweigert) und FAILURE (Fehler).
Die Ursachencodes sind AUTHN_SUCCESS, AUTHN_LOGIN_EXCEPTION und AUTHN_PRIVILEDGE_ACTION_EXCEPTION.
In der folgenden Tabelle sind die Authentifizierungsereignisse zusammengefasst:
Tabelle 6. Prüfereignisse für die Authentifizierung. Sie können die Prüfereignisdatensätze analysieren, um mögliche Sicherheitsverstöße
oder potenzielle Schwachstellen in der Sicherheitskonfiguration Ihrer Umgebung zu identifizieren.Ereignistyp |
Mögliche Ergebnisse |
Ursachencodes |
SECURITY_AUTHN |
SUCCESS
DENIED
FAILURE
|
AUTHN_SUCCESS
AUTHN_LOGIN_EXCEPTION
AUTHN_PRIVILEDGE_ACTION_EXCEPTION
|
Delegierung
Die Authentifizierung einer SOAP-Nachricht kann delegiert werden, und die
Delegierungsfunktion wird mit einem SECURITY_AUTHN_DELEGATION-Ereignis geprüft.
Dieses Ereignis wird gesendet, wenn die Clientidentität weitergegeben wird oder wenn die
Delegierung die Verwendung einer speziellen Identität umfasst.
In der Laufzeitumgebung von Web Services Security werden Prüfereignisse nur aufgezeichnet, wenn der
Delegierungstyp auf Identitätszusicherung eingestellt ist.
Die möglichen Ergebnisse sind SUCCESS (Erfolg) und DENIED (verweigert) und die Ursachencodes AUTHN_SUCCESS und AUTHN_DENIED.
Zusätzliche Informationen, wie z. B. der Delegierungstyp, der Rollenname und der Identitätsname, werden erfasst und im Prüfereignissatz aufgezeichnet.
In der folgenden Tabelle sind die Delegierungsereignisse zusammengefasst:
Tabelle 7. Prüfereignisse für die Delegierung. Sie können die Prüfereignisdatensätze analysieren, um mögliche Sicherheitsverstöße
oder potenzielle Schwachstellen in der Sicherheitskonfiguration Ihrer Umgebung zu identifizieren.Ereignistyp |
Mögliche Ergebnisse |
Ursachencodes |
SECURITY_AUTHN_DELEGATION |
SUCCESS
DENIED
|
AUTHN_SUCCESS
AUTHN_DENIED
|
Validierung
Im Rahmen der Unterstützung für das Anmeldemodul des generischen Sicherheitstokens kann ein
Sicherheitstokenservice ein Token mit einer Anforderung vom Typ
WS-Trust Validate validieren.
Bei dieser Validierungsoperation kann ein Token im Tausch für ein zu validierendes Token zurückgegeben werden. In der Dokumentation
zu Prüfvorgängen für generische Sicherheitstoken werden die auszutauschenden Informationen genannt. In der folgenden Tabelle
sind die Informationen zum Tokenaustausch, die aufgezeichnet werden, aufgeführt:
Tabelle 8. Tokenaustausch . Verwenden Sie die Informationen zum Tokenaustausch, um den Austauschprozess zu überwachen. Ereignis |
Beschreibung |
TokenSentForExchangeId |
Gibt das Token an, das zur Validierung gesendet wird und ausgetauscht werden soll. |
TokenSentForExchangeType |
Gibt den Tokentyp an, der zur Validierung gesendet wird und ausgetauscht werden soll. |
ExchangedTokenId |
Gibt das Token an, das während der Validierungsanforderung beim Tausch empfangen wird. |
ExchangedTokenType |
Gibt den Tokentyp an, der während der Validierungsanforderung beim Tausch empfangen wird. |
Wenn das Token ohne Tokenaustausch validiert wird, wird nur die Token-ID aufgezeichnet.