Interesting - took me a few passes to "unpack" this.
As I understand you, the concern is that if "database code" (packages,
procedures, etc) is stored in the database as "clear text" then "any random
user" with elevated privileges can change said code.
And the solution this client is using is to "wrap" the code, and presumably not
give the "3rd parties" access to the "unwrapped" code, so that what's stored
in the database CANNOT be modified (much like Oracle does or used to do with
some of the "internal" procedures).
I suppose in a situation where:
1. You have little or no "control" over "3rd parties"
2. Absolute security/traceability is critical
This is probably as good a solution as any - but, as you note, there could be
some drawbacks. I've found that "helping" those with elevated privileges
understand the responsibilities that go with them AND the "consequences" of NOT
taking those responsibilities seriously can go a long way toward "managing"
situations like this. While I don't advocate floggings; severe PUBLIC
consequences can definitely encourage "proper behavior" among the "survivors".
Of course, at some point, you have to trust someone
Really sounds like a rather typical "risk vs cost/reward" analysis.
Clay Jackson
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> On Behalf
Of Michael D O'Shea/Woodward Informatics Ltd
Sent: Monday, July 25, 2022 7:59 AM
To: ORACLE-L (oracle-l@xxxxxxxxxxxxx) <oracle-l@xxxxxxxxxxxxx>
Subject: Oracle code wrapping
CAUTION: This email originated from outside of the organization. Do not follow
guidance, click links, or open attachments unless you recognize the sender and
know the content is safe.
I just had a discussion with the development manager/tech lead of a large
organisation. He manages a team of around 15 developers and QA staff for a
single financial product. Client-side code is
ASP.NET<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fasp.net%2F&data=05%7C01%7Cclay.jackson%40quest.com%7C2d01c0d12bfa41fd2e3608da6e4e3a00%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637943579509111570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iYMe%2FNYfMyO9fUwQWsl5dkvZCcG93zXGFJM%2FLv5zLqo%3D&reserved=0>
and a desktop thin client, and server-side it is Oracle 19c with a web service
in-between in a few places.
Deployments are done weekly after UAT signoff of the prior development sprint
the week before.
This chap was expressing his concerns about PSM's, specifically database
packages, procedures, and functions, being constantly tampered with by DBA's
and sysops, and not marrying up with the authorative version of the codebase
under source control. His argument was that the version of the code deployed,
using automation tools, should be bit for bit compatible with the code
retrieved from source control. It seems hard to argue with this perspective.
Then he mentioned that they, recently, have got around the issue of this
third-party "tampering" rather than by enforcing business controls and process,
but by "wrapping" the code during deployment.
I did not know how to reply.
Does anyone have any views on this approach? The only tangible information I
can pull out from the docs is that wrapped code may not be version upgrade
compatible, meaning possible upgrade issues. I know so little about "wrapping"
to know the drawbacks, specifically performance or stack traces and errors
thrown.
All/any feedback, no matter how qualitative, would be helpful,
Mike
http://www.strychnine.co.uk<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.strychnine.co.uk%2F&data=05%7C01%7Cclay.jackson%40quest.com%7C2d01c0d12bfa41fd2e3608da6e4e3a00%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637943579509111570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ApH0q7GHHiPsgUItvtqBDBTLsHzGh%2FpmdF%2FWKBYl6Dk%3D&reserved=0>
Woodward Informatics Ltd
