Imagine a huge landscape with multiple Weblogic domains where each domain has multiple administrators, operators and deployers working with the Weblogic console. Wouldn’t it be great if you could audit the changes that where made during each Lock & Edit session. Especially when your business requires this due to strict regulations.
The good news is: You can, but there are some small details you should be aware of.
Auditing with Weblogic logging:
In the Weblogic console click on the domain to the left, and then on the right select the Advanced section in Configuration -> General. One of the settings here is the Configuration Audit Type.
The setting has 4 values, where None is the default:
- None = Configuration events will neither be written to the server log or directed to the Security Audit Framework.
- Change Log = Configuration events will be written to the server log.
- Change Audit = Configuration events will be directed to the Security Audit Framework.
- Change Log and Audit = Configuration events will be written to the server log and directed to the Security Audit Framework.
The easiest part is to use the Change Log option, the audited changes will be written to the Weblogic server log. The following example is copied from the AdminServer.log. It shows the audit trail of a simple change to the environment where 2 ports are changed for a Managed Server.
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159907> <USER weblogic INVOKED ON com.bea:Name=rbx_dev_osb_01,Type=Server METHOD isSet PARAMS ListenAddress>
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159907> <USER weblogic INVOKED ON com.bea:Name=rbx_dev_osb_01,Type=Server METHOD isSet PARAMS ListenPortEnabled>
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159907> <USER weblogic INVOKED ON com.bea:Name=rbx_dev_osb_01,Type=Server METHOD isSet PARAMS ListenPort>
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159904> <USER weblogic MODIFIED com.bea:Name=rbx_dev_osb_01,Type=Server ATTRIBUTE ListenPort FROM 8010 TO 9010>
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159907> <USER weblogic INVOKED ON com.bea:Name=rbx_dev_osb_01,Type=Server METHOD isSet PARAMS JavaCompiler>
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159907> <USER weblogic INVOKED ON com.bea:Name=rbx_dev_osb_01,Type=Server METHOD isSet PARAMS ClientCertProxyEnabled>
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159904> <USER weblogic MODIFIED com.bea:Name=rbx_dev_osb_01,Type=SSL,Server=rbx_dev_osb_01 ATTRIBUTE Enabled FROM true TO true>
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159904> <USER weblogic MODIFIED com.bea:Name=rbx_dev_osb_01,Type=SSL,Server=rbx_dev_osb_01 ATTRIBUTE ListenPort FROM 8011 TO 9011>
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159907> <USER weblogic INVOKED ON com.bea:Name=rbx_dev_osb_01,Type=WLDFServerDiagnostic,Server=rbx_dev_osb_01 METHOD isSet PARAMS WLDFDiagnosticVolume>
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159907> <USER weblogic INVOKED ON com.bea:Name=ConfigurationManager,Type=weblogic.management.mbeanservers.edit.ConfigurationManagerMBean METHOD save PARAMS >
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159907> <USER weblogic INVOKED ON com.bea:Name=ConfigurationManager,Type=weblogic.management.mbeanservers.edit.ConfigurationManagerMBean METHOD haveUnactivatedChanges PARAMS >
####<someDate> <Info> <Configuration Audit> <someNode> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <...> <BEA-159907> <USER weblogic INVOKED ON com.bea:Name=ConfigurationManager,Type=weblogic.management.mbeanservers.edit.ConfigurationManagerMBean METHOD haveUnactivatedChanges PARAMS >
As you can see, it’s a lot of logging for such a simple change. The second bad part here is that the Weblogic log files are already cluttered with information, and it might be hard to find such specific information. Another problem might be that the log level is apparently fixed set to INFO. In most production domains I don’t want such a low log level due to log files getting to huge and containing to much non-information. So in general situation the Logger Severity is set to Notice or even Warning (located under each Admin / Managed Server at Logging -> General -> Advanced ).
Auditing with the Weblogic Auditing Provider:
The solution for the cluttered Weblogic server logging is to use the “Change Audit” option. The information will be redirected to the Weblogic Security Audit Provider (if configured) and send to a separate DefaultAuditRecorder.log file.
An auditing provider is collects, stores, and distributes information about operating requests and the outcome of those requests for the purposes of non-repudiation. An Auditing provider can also handle information about configuration changes for auditing purposes. You can configure multiple Auditing providers in a security realm, but none are required. The default security realm does not include an Auditing provider. (source: Weblogic Console)
First we set the Configuration Audit Type option to Change Audit and secondly we will need to configure a Security Audit Provider in the Weblogic Security realm.
You can add the default Audit Provider under Providers -> Auditing.
The Default Auditor is limited in it’s configuration so we can only configure the Log Severity, Log Rotation Level and the Begin and End Markers shown in the log file example below. When we change the configuration from a Managed Server again (the ListenPort) we can find the following lines in the DefaultAuditRecorder.log.
#### Audit Record Begin <someDate>
<Severity =SUCCESS> <<<Event Type = SetAttribute Configuration Audit Event>
<Subject = Subject: 4
Principal = class weblogic.security.principal.WLSUserImpl("weblogic")
Principal = class weblogic.security.principal.WLSGroupImpl("Administrators")
Principal = class weblogic.security.principal.WLSGroupImpl("IntegrationAdministrators")
Principal = class weblogic.security.principal.WLSGroupImpl("AdminChannelUsers")>
<Object = com.bea:Name=rbx_dev_osb_01,Type=Server>
<Attribute = ListenPort><From = 6010><To = 7010>>>
Audit Record End ####
As we can see the modification has a SUCCESS severity, so again we don’t leave the default settings for the Security Audit Provider because the DefaultAuditRecorder.log is growing very rapidly. For now my conclusion is that it is more wise to set the Severity option to CUSTOM and use the Error, Success and Failure Audit Severity. Information Audit Severity will fill up your disks very fast.
However, the Default Audit Provider is connected to your security realm. So during startup of your domain many information is send to this file regarding roles, policies and deployments. Again it’s possible to find configuration changes, this time easier then in the general Weblogic log files, but still it might take some time to find specific settings and changes over time. Another detail is that the DefaultAuditRecorder.log is located in the default server log folder. So we might have to guarantee strict access to these files if we need them for legal audit purposes.
WLST Script Recording:
This might sound as a strange alternative, but WLST script recording could help us in some way. Of course WLST (Weblogic Scripting) is very cool for setting up complete new Weblogic environments in seconds. And besides that it’s also very handy for releasing configuration changes to your domains from development all the way to production.
You can of course start hardcore coding your scripts, but another helpful tool is the Record option the Weblogic console has to offer. This feature will record the changes you make in your configuration and save them as a generated Jython script which you can then (if necessary) modify and run on other environments.
If you check the preferences of your Weblogic domain you can find a WLST Script Recording tab
Which has an option called “Automatic Recording”
By enabling this option you actually get what you want, all changes are automatically written to disk in the location configured by the “Base Script Directory” option. However for some weird reason the “Script File Name” option which states that the filename is generated dynamically every time you Lock & Edit, is now a static value. So if you don’t realize this, the file “Script1316….” will be overwritten every time you make changes. To avoid this you could enable the “Append to File” option, but my opinion is that this is just a workaround and you would rather have:
- A random generated output file name, instead of the static value you create by enabling the “Automatic Recording” option.
- It would be a nice-to-have to be able to use parameters in the output file, like %date% or %username%.
There is another “problem” if you are the highest Weblogic Administrator in the domain and the business wants a feature for “audit and proof”. The problem is the fact that the setting is not set for the whole domain, as I would have hoped but for every user independantly. So right now we only set this configuration for the user “Weblogic”
For instance, when I log on with a new user called “Test” (which is member of the Operators and Deployers groups) we can see that the settings were not inherited.
The Base Script Directory is configured with the default (the domain home) and the Automatic Recording is disabled. While we do create users with WLST scripts it’s quite easy to configure both these settings correctly. But for audit purposes it has no use if the user itself is able to disable the whole setting.
It would be great to have this feature “improved” in feature Weblogic versions (this was tested with Weblogic 10.3.5). So that the whole Automatic Recording functionality is extended to be more like an internal security audit mechanism as the Weblogic Security Audit Provider.
Conclusion:
It looks like the Security Audit Provider in combination with the Configuration Audit Changes option is still the best solution for auditing a Weblogic domain. During the first period you configure it monitor the outcome to see if you audit to much or to less of details.
WLST Script Recording is very cool, but we can not guarantee to record all changes in the domain. So I would advise to use it, but more for the cases where you are debugging some issues in you domain. At any time you can check what changes you made and if necessary roll them back. So handle it more as a helpful reminder option.
766
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
