Imagine you are able to lock down the .ped files, what are you going to when you find a .ped file with contents:
Code:
run mindyourownbusiness.p
Fire the user and hope they did not do anything too malicious?
Exactly. Or the user could run applicationstartprocedure.p, which is the name of the procedure that everyone runs, except that unbeknownst to you their copy is modified to do something different. And the modified copy can be replaced before you get a chance to check it.
It sounds like the requirements are coming from someone who doesn't really understand the platform.
The fact that you are still using a fifteen-year-old version of OpenEdge doesn't help your compliance situation and limits some of your options. It should definitely be deemed an important issue by any auditor worth their salt.
You could:
- implement OpenEdge Auditing so you have a record of changes to any tables you care about;
- implement a robust authentication mechanism so that your audit trail is meaningful, and lock down your database (e.g. prevent blank-user access);
- uninstall the compiler licence to prevent session compiles of unauthorized code;
- implement dbauthkey or package your application code in signed archive libraries (.apl) (OE 12.7+) to limit the r-code files that can be executed against your database.
Each of these steps will have limitations and operational impacts that you will need to understand, and none is a simple turnkey solution that will identify and prevent "bad guys" from doing "bad things" while allowing "good guys" to do authorized work with no impacts. For example:
- If you remove the compiler licence, that will impact your DBAs; it limits their options with dump and load. It also may affect break-fix procedures. Do you understand what do your developers do today to implement data fixes in production?
- If you implement OpenEdge Auditing, there are many impacts:
- Who is going to determine your audit events and policies, and your audit data retention policy? Do they understand OE Auditing and the impact of their decisions?
- Implementing auditing can significantly impact your system and database read and write workload.
- Your backups will be larger and slower, and you will have a new audit archive database to maintain and secure, and you will have new processes for dumping and loading audit data, and eventually deleting it.
- If you audit changes to everything, you are going to create massive amounts of audit data.
- Who is the trusted auditor who will review that data, and how often, and based on what events?
- Who will write the application that the auditor will use to review the data?
- How will they differentiate authorized versus unauthorized data access?
- You have to have a compiler installed somewhere. What will prevent a backup of the production database from being restored and accessed there? What will prevent a developer or dev ops tech from writing unauthorized code and compiling it there and using the .r in production?
- If you use dbauthkey or .apl, how are you implementing key life cycle management? How will you detect key compromise or improper key use, e.g. unauthorized creation of signed code? Who watches the watchers?
- What stops a DBA or sys admin from just bypassing the application and runtime altogether and sucking the data straight out of the database files? (Yes, that's possible when one is sufficiently informed and motivated.)
Solving these problems is hard. Defining the scope of the problems and determining which problems can be addressed in meaningful ways as opposed to implementing impotent and intrusive "security theatre" is equally hard. And to make matters worse, I can say from experience that sometimes the business decision-makers in an organization can't be bothered to learn enough about the capabilities and limitations of the OpenEdge platform and about their in-house operational procedures and application data flows to be able to reason about these problems, so they foist those tasks on the implementers with a mandate to "just fix it!" Or, as they say, "
stuff runs downhill".
Good luck!
