| Object Security in App Designer | KEVIN RESCHENBERG
02-01-2006 |
Today I'd planned to start talking about some
of the options and considerations in using
Application Designer for migrations. But a
relevant question from a reader seems to be
a better place to start.
Tom writes:
I specialize in auditing clients who use either
PeopleSoft Financials or HRMS environments.
We continually look at how we can improve our audits,
and one item that I am looking to get a better
understanding around is the need of Application Designer
access in the production environment. As auditors,
we view this access as very risky, and therefore
would want to see this as restricted as possible.
Obviously there is always give and go between auditor
and client around required access, etc. I only
have auditing experience with the application,
and therefore do not have a significant amount
of knowledge around the actual use of this development
tool. From our point of view, access to App Designer
in the production database should be used for the
purpose of migrating changes only. This leads to
the debate of what level of access to which definitions
in Application Designer is actually needed in order
to perform these migrations. I've had a couple
conversations with various people, but never have
gotten a definitive answer as to the minimum
access needed in order to perform upgrades/migrations
from a test/development environment to a production
environment. Would you be able to help me out?
PeopleTools offers a feature called "object security."
This gives you the ability to grant or restrict access
to certain App Designer functions, object types, and/or
specific objects. But it's a little tricky. Some of
it is located under Maintain Security, but setting
an object type to "read only" or "no access" there
didn't seem to have any effect. There is a utility
under Go | PeopleTools | Object Security. The
PeopleTools Security book describes this utility,
which is a quirky, ancient-looking (at release 8.1x, anyway)
thing. I was able to restrict a particular field
object to display-only status for a user ID. So far,
so good.
But there's a problem. By logging on to another
environment, I was able to migrate a change to this
object using the user ID that was supposedly restricted.
Therefore, if we were considering the production
environment, it appears that I could easily change
an object by migrating it from somewhere else.
Now, that may be OK. It depends on what we are talking
about. If we're trying to prevent accidental changes
directly in the production environment,
this functionality can be very useful. It also helps
to keep the environments in sync (although it's only a
very little bit of help with that). In reference to Tom's point,
this setup would allow me to migrate objects, which
is what we want, without changing them directly.
Remember also that there are objects not managed by
App Designer. SQR and COBOL programs, Crystal Reports,
scripts, etc. must be secured through the file system.
Now, many installations' policies actually require direct changes
to certain objects. For example, many companies don't
migrate menus. Instead, they modify them directly
in production. This tends to be the safer choice in
most cases when there is significant ongoing
development activity. Permission lists are another obvious
example, and some companies include other objects
in this group. Therefore, you should expect to have
direct access to some object types in production.
Exactly which objects this affects will depend
on local situations. Also, remember to give the
migrator the ability to build tables and views.
And so, Tom, I know this is
a weak answer to your question. Sorry about that.
We can't eliminate all risk. In fact, too much security
opens up its own types of risk. Can you apply an
emergency fix to the production database? If not,
or if it takes too long to do so, or if the one person
able to do it is on vacation, that's a bad situation.
But although most of us who are developers would like
to have full access to everything, I'm definitely
not advocating that.
Some companies have given the production migration
responsibilities
to the DBAs, a manager, or a separate group.
That's fine as long as these migrators add some
value. If they don't know anything about App Designer
and PeopleSoft objects and therefore require a detailed step-by-step
instruction form, complete with a list of each
object to be migrated, it's a big risk.
If you have such a form, it's a good indication
that you might need to rethink your processes!
I'll probably rant about that more in a future post.
We all want to protect our production environment.
But I'm worried when I see an installation in
which the production database is protected like
a bank vault but the development and testing
environments are treated like free-for-all
sandboxes. Remember that what's sitting in dev and test
environments will eventually get migrated to
production. It might happen as part of your
project, but unwanted changes also could be swept up
by another project or an upgrade.
Don't allow full App Designer access for anyone
except qualified developers. Display-only access
is fine. But to allow, say, a functional
team member or tester to change objects in
an environment that's on the migration path
is extremely risky. Even if they would never
intend to change something like a record definition,
there can still be problems. It's easy to
save changes inadvertently due to the
project-save mechanism. Also, for example, I've
seen many situations in which the functional
team members maintain translate table values. Do they realize
that even adding a new translate value
can cause programs to crash? Test data
does not need to be as secure from changes as production data,
but development and test objects are almost as
worthy of protection as production
objects.
Well, it's a big subject. Everybody has opinions
on it, but I'm not sure anyone will have the
definitive answer.
|
