Progress editor

[ctoman]

OE 10.2B
OS: Ubuntu 18

I know old version of Progress.

Auditors are all over my buttocks about DBAs accessing the Progress Editors. Any suggestions.
1. Disable the editor - change permissions on mpro to read only.
2. OS shell access.

Thanks in advance!

 

[Rob Fitzpatrick]

DBAs accessing the Progress Editors

What is the perceived risk that this action would mitigate?

2. OS shell access.

This is an incomplete thought. I don't know what you are trying to say or ask. Please clarify.

Clearly, however, it would be foolish for someone to suggest preventing a DBA from having shell access on a database server. That would strongly suggest that they don't understand what DBAs do.

1. Disable the editor - change permissions on mpro to read only.

That wouldn't have the desired result.

• Why would someone want or need to modify mpro, and how would that protect the database? Removing the execute permission? That's not going to slow anyone down.
• mpro is a shell script. Even if you did something to lock it down in a way that prevented its current use, someone could just make another script that is an exact copy of mpro and you would be no further ahead.
• By doing so you would be breaking any existing procedures or scripts that rely on mpro.
• OpenEdge DBAs write and execute ABL and SQL code as a core part of their job function. People who don't know that shouldn't be making rules about what DBAs can and can't do. Putting roadblocks in their way will eventually backfire in a spectacular way when they need to write code during the resolution of some emergency, and the roadblocks slow them down, extend the outage, and cost the company money, reputational risk, and customer goodwill.
• There are other ways to access the database apart from mpro.

The tail is wagging the dog here.

This sounds like someone (the auditor, not you) is fumbling in the dark by suggesting solutions to an as-yet unarticulated problem.

OpenEdge 10.2B08 reached retired status over four and a half years ago. It hasn't seen a bug or security fix in years, and it never will again. That's a significant risk now and it grows by the day. I think that should be a focus for the auditors. And Ubuntu 18 is no spring chicken either.

 

[ctoman]

Thanks for your opinion, Rob.

I know it is crazy.

 

[ctoman]

The procedure editor is a great tool, however, security is a concern and data is another problem. Anyone can connect to OE DB using procedure editor and change data. How can the PE to DB have security controls (who is allowed access to PE}? Is there a feature already, or can logging be enabled? We have controls at the OS layer (sudo).

Thanks,

 

[peterjudge]

How can the PE to DB have security controls (who is allowed access to PE}? Is there a feature already, or can logging be enabled?

One feature that the OEAG (OE Authentication Gateway) added was the ability to control which users can connect to a database (using RBAC). This is not specific to the procedure editor (or any particular client for that matter), but rather to the DB connection. This functionality is however only available as part of using the OEAG, which was released in 11.6.something, if memory serves.

In 10.2B, you could probably look at using the auditing feature to record user logins and logouts and other kinds of things (see https://docs.progress.com/bundle/op...he-preconfigured-OpenEdge-audit-policies.html and related docs). Auditing was added to 10.0A or some similarly aged release.

 

[Rob Fitzpatrick]

OE Auditing was added in 10.1A.

 

[TomBascom]

I have added logging of such access, via OE Auditing, in the past as a result of “auditor concerns”. Part of that also involved writing some reports to demonstrate compliance. Or at least report on when the access was used.

The work was done for a bank and I probably had to bill them for at least a couple of weeks of effort given all the hoops that I had to jump through…

 

[ctoman]

The auditors want to audit the DBAs, not just access to the database, they want to see what data changes the DBA do.


Thanks,

 

[Rob Fitzpatrick]

The auditors want to audit the DBAs, not just access to the database, they want to see what data changes the DBA do.


Thanks,

That's non-trivial. It will be relatively straightforward to enable OE Auditing, assuming familiarity with the documentation. As with many other database features, there are OE Auditing best and worst practices and that is a lengthy (and separate) discussion topic. You can find some of that with a site search here.

But OE Auditing, in and of itself, isn't a complete solution that will just give your auditors what they want. Once implemented and configured (which also requires some business decisions to be made; it isn't just technical work), you have raw audit data. There is no OpenEdge audit data viewer/analyzer tool or application. You have to design and build that yourself. You also have to think hard about the life cycle of the data, define it rigorously, and implement policies and procedures to enforce it.

"What data changes the DBAs do" could mean any create/update/delete operation on any table. So if you don't audit everything, the audit trail will be incomplete. Of course that also means having a business process for ensuring that you continue to modify the auditing configuration as the scope of "everything" changes when the application schema does. Auditing everything is a lot of work and, depending on write volume, may generate enormous amounts of audit data and the accompanying BI/AI volume increases and their various effects. Again, don't ignore the best practices or else you (or your successor) will regret it.

Also, give some thought to the idea that OE Auditing is implemented by the DBA.

Good luck!

 

[TomBascom]

"Auditors want" is always a bit of a rabbit hole