Question After Imaging Files

C

ctoman

New Member
OE 10.2B
OS: AIX and Ubuntu

What are the PROS AND CONS of using the After imaging logs for reporting CUDs VS the Audit Policy Maintenance tool for reporting CUDs?

Thanks in advance!

Happy Friday!
 
This seems like a very odd comparison to be making. Perhaps you could elaborate on why you are comparing these two?

As James says, one tool (OE Auditing) is explicitly designed for that purpose and is known to deliver those results reliably with a modest amount of initial configuration and ongoing maintenance.

In theory, you could (with an awful lot of work) possibly subvert after-imaging to do something similar by interpreting the verbose ai logs. But I would expect whatever you might come up with would require a pretty serious investment of up front effort to decode the ai logs and that you will need to invest regularly in updating that technology and that the ongoing maintenance will also be substantial.

Another way to collect this kind of data is with triggers. The downsides to that are that triggers can be bypassed in various ways and the audit logs can be tampered with. But depending on why you want the audit data that might not be a big problem.

You are on OpenEdge 10.2B but the other possible alternative would be "Change Data Capture" which is available from 11.x (11.4?) forward. You have the same exposure to tampering with the logs as with triggers but, otherwise, this can be a pretty solid approach.
 
Thanks everyone!

We are a public company and the auditors got wind that DBAs could back door into the database and make changes (editor), without any traceability, so we have to come up with a solution to track CUDs. My partner suggested that AI files could be a solution to write ABL code to get the auditors off our back. We are concern with OE auditing would hinder database performance. I think you or someone said you will see a 10 percent decrease in performance. i have a plan, and created some scripts to archive data to another server/DB.

OpenEdge Database Auditing

Auditing goal can be achieved through below steps:

1. Enabling Audit in a DB.

2. Implementing policies.

3. Generating reports.



MXOpen Production Databases

SPSX Audit Archival Utility









​

EDBPRO EDBTEST

Application DBs Long Term Storage







Reporting




Audit Data

.abd file





_proutil db-C auditarchive _proutil db -C auditload
 

Attachments

CDC was introduced in 11.7.

"Reporting CUDs" isn't much of a business requirement. If you were asking me personally, I'd want much more of an explanation of what you want to accomplish before recommending a solution. But I am confident that solution wouldn't involve parsing aimage scan verbose logs.

It's also a little curious to me that you specifically called out the Audit Policy Maintenance Tool, as opposed to saying OpenEdge Auditing. That tool is for managing audit policies, not for reporting.
 
ctoman said:
My partner suggested that AI files could be a solution to write ABL code to get the auditors off our back. We are concern with OE auditing would hinder database performance.
Click to expand...
I've written here at some length about OE Auditing in the past. It involves extra work (reads, writes, BI/AI note volume), and work isn't free. It has a computational and storage cost. But that isn't a reason to avoid it; compliance requirements trump performance desires. And performance deficits can be offset with better hardware.

There is a lot to read about OE Auditing in the docs, and you should read *all* of it before making a plan. Be aware that Progress doesn't provide everything you will need to implement an auditing solution. Some of it (archiving processes, code to read and interpret audit data, audit data life cycle management) you will need to build yourself. Test extensively before going live.
 
My bad, i thought that OE auditing is the Audit Policy Maintenance tool are the same, just rebranded by Progress. I will do more research.
The requirements are to get auditors off our back, just kidding. The auditors' requirements are not straight forward; however, the auditors want a report on who, what, and where the changes occur.
 
Last edited:
ctoman said:
My bad, i thought that OE auditing is the Audit Policy Maintenance tool are the same, just rebranded by Progress.
Click to expand...

It is probably the other way around. Your vendor has likely "rebranded" some of the Progress tooling and, quite possibly, added some additional tooling to simplify maintenance tasks (like archiving audit logs). Maybe even some reporting.

As far as "a DBA login is backdoor to..." well, duh. Do the auditors realize that an Oracle DBA or an MS SQL DBA can also run wild? To actually lock things down you need a to do a lot more than enabling auditing or parsing after-image logs. Rob is probably typing a long essay on the topic right now ;)

But, just for starters, you might consider removing development licenses from production. I know that it is _convenient_ to run an ad-hoc query from the tram lines but it's really not a good idea to be permitting that. If you have not already done so you should also disable blank user access and make sure that CAN-* permissions are set appropriately. If you get that stuff tightened up you might be able to satisfy the auditors by tracking logins, and documenting (perhaps with a support ticket) why you logged in. A narrow focus of auditing "dangerous" activities (like changing security settings) might then be sufficient (I know of some big banks where that was the solution).
 
You must log in or register to reply here.
Back
Top